Subject: Taxonomy: Security considerations

From: Ingrid Melve <[email-masked]>
Date: Wed, 01 Sep 1999 15:48:29 +0200

Hi,

this is an update of the security considerations for the taxonomy 
draft.  Following the discussions I have tried to incorporate more 
information on replication, with some emphasis on redirection/location.

The section has be reformatted according to the discussion at the Oslo 
IETF.  I tried to be brief, while still stating the obvious, if it is 
too brief (or too wordy) please let me know.

Comments and questions and clarifications, anyone?

9. Security Considerations

   Replication and caching means copying objects. There are legal 
   implication of making and keeping transient or permanent copies, 
   these are not covered in the security considerations.

   Information on security in each protocol is provided in the
   description of the protocol, and in the accompanying documentation
   of each protocol. HTTP security is discussed  RFC2616[6], the 
   HTTP/1.1 specification, and to a lesser extent  in RFC1945, the 
   HTTP/1.0 specification.  RFC2616 contains security consideration 
   for HTTP proxies.

9.1 Authentication

   [Ed. note: Section name is misleading.  Need to cover the threesome:
   noone has read, noone has changed, identified culprit.

9.1.1 Man in the middle attacks

   HTTP proxies are men-in-the-middle, the perfect place for a
   man-in-the-middle-attack.  A discussion of this is found in section
   15 of RFC2616[6].

9.1.2 Trusted third party

   A proxy must either be trusted to act on behalf of server and/or
   client, or it must act as a tunnel.  When presenting cached objects
   to clients, the clients need to trust the caching proxy to act on
   behalf on the origin server.

   A replica may get accreditation from the origin server.

9.2 Privacy

9.2.1 Trusted third party

   When using a replication service, you need to trust both the replica
   and the object location service.  A object location service is used
   to find the replicated object.  Current examples include DNS round
   robin, manual mirror lists, URNs, HTTP redirecting.

   Redirection of traffic, either by redirecting to replicas or by
   redirection done by proxies, may introduce third parties the end user
   and/or origin server need to trust.  In the case of network
   transparent proxies, such trusted third parties are often unknown to
   both end points of the communication.  Unknown trusted third parties
   may have security implications.

   Both proxies and location services may have access to aggregated
   access information.  A proxy typically knows about all access by all
   the clients using it, information that is more sensitive than the
   information held by one origin server.

9.2.2 Logs and legal implications

   Logs from proxies need to be kept secure, as they provide
   information about users and end user patterns.  A proxy log is even
   more sensitive than a web server log, as all requests from the user
   population goes through the proxy. Logs from replication servers may
   need to be amalgamated to get aggregated statistics from a service,
   transporting logs across borders may have legal implications.  Log
   handling is restricted by law in some countries.

   Requirements for object security and privacy are the same in a web
   replication and caching system as it is in the Internet at large. 
   The only reliable solution is strong cryptography.  End to end
   encryption does not necessarily make objects cacheable, as is the
   case of SSL encrypted web sessions.

9.3 Service security

9.3.1 Denial of service

   Any redirection of traffic is susceptible to denial of service
   attacks at the redirect point, and both proxies and location 
   services may redirect traffic.  

   By attacking a proxy, access to all servers may be denied for a
   large set of clients.

   It has been argued that introduction of a network transparent proxy
   is denial of service since the end to end nature of the Internet is
   destroyed without the end users knowledge.

9.3.2 Replay attack

   A caching proxy is by definition a replay attack.

9.3.3 Stupid configuration of proxies

   It is quite easy to have a stupid configuration which will harm
   service for end users.  This is the most common security problem
   with proxies.

9.3.4 Copyrighted transient copies

   The legislative forces of the world are considering the question of
   transient copies, like those kept in replication and caching system,
   being legal.  Legal implications of replication and caching is
   subject to local law.

   Caching proxies need to preserve the protocol output, including
   headers. Replication services need to preserve the source of the
   objects.

9.3.5 Application level access

   Caching proxies are application level components in the traffic 
   flow path, and may give intruders access to information that was 
   only available at network level equipment in a proxy-free world.
   Some network level equipment may have required physical access 
   to get sensitive information, and introducing application level 
   components may require additional system security.

Ingrid
  PS: those who went to Oslo may enjoy my penguin's travel report at
      http://domen.uninett.no/~im/krkgt/inez/ietf45.html

---

From: Ingrid Melve <[email-masked]>
Date: Fri, 24 Sep 1999 16:12:47 +0200

> Comments and questions and clarifications, anyone?

I have had no comments so far.  That is scary.
One excuse heard is "it was summer", but in this country September does not 
count as summer...

If you think security is covered adequately in the following, please 
let me know.