> 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?
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.
> 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
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:27 MST