Subject: RE: [rddp] RDDP and Security Scenarios

From: "Williams, Jim" <[email-masked]>
Date: Wed, 27 Nov 2002 14:30:17 -0500

Good summary Caitlin.

I would make a couple other observations,
which are possibly obvious.  (or possibly
wrong. :-)

1.  If there are a number of endpoints in
    a physically secure location which need
    to communicate over an insecure network,
    it is preferable to use a single firewall
    type VPN rather than end to end security.
    This is because it is far less work for
    administrators to configure and manage,
    and it is safer because of much lower probability
    that the administrator will accidently 
    misconfigure and cause security holes.

2   If an endpoint is not physically secure,
    it is nice to have some level of network
    security.  Basic stuff like avoiding 
    cleartext passwords should certainly
    be done.  But, it is not worth a lot
    of cost or effort because the endpoint
    itself is almost always a much easier and
    more vulnerable target for the attacker
    than the network.

> -----Original Message-----
> From: Caitlin Bestler [mailto:[email-masked]]
> Sent: Wednesday, November 27, 2002 12:17 PM
> To: [email-masked]
> Subject: [rddp] RDDP and Security Scenarios
> 
> 
> The problem with addressing the interoperabilty of RDDP and
> fulll security is that there are simply too many viable
> scenarios. I will list several in this memo. The point is
> not to attempt to address them all, but rather to point out
> the futility of attempting to do so. I firmly believe that
> the goal of the group should be to ensure that the local
> interface is adequately defined so that *it* does not create
> new security holes. However providing true security will
> always remain a ULP issue.
>
> [...] 
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: [email-masked]
Date: Wed, 27 Nov 2002 16:12:22 -0500

> The problem with addressing the interoperability of RDDP and
> full security is that there are simply too many viable
> the futility of attempting to do so.

The general approach to this issue is to:
(1) take requirements from scenarios like 3 and 4 below,
	where the intervening network and those who have access
	to traffic on it cannot be trusted and may be out to do
	harm,
(2) specify the security  mechanisms required to meet those
	requirements as "MUST implement", and
(3) allow the user of the deployed equipment to choose what
	to use in order to meet his/her security requirements.

While explaining how to deploy the available tools in each
scenario may be a bit much, it is not futile to provide the
tools that these sorts of scenarios require.  Some of the
needs for tools may be satisfiable by appealing to the ULP
- cf. the NFSv4 discussion on not duplicating key negotiation.

OTOH, Scenario 7 (Sealed Storage) is out of scope, as its
storage aspects change the problem in some rather dramatic
ways from network communication security domain - key management
in particular changes dramatically, both due to the long term
storage of the data and the probable requirement to be able
to decrypt on a system other than the one that did the original
encryption.

> Scenario 3: Road Warrior
> 
> Laptop must transfer data back to home network, over a
> variety of different networks. Uniform security must apply
> whether the connection is established via the wireless port,
> the Ethernet port or the dial-up modem.
> 
> 
> 
> Scenario 4: Public Server
> 
> Server deals with many connections received over the public
> network from a wide variety of clients. All connections
> arrive via a single high speed RNIC or its backup.
> 
> Such a server would truly benefit from RNIC encryption,
> espeically if standardized such that all of its clients
> would adopt the same solution.
> 
> 
> Scenario 7: Sealed Storage
> 
> Host wishes to have the RNIC encrypt data writeen to remote
> storage device on write, and to decrypt it on read. The
> remote storage device never needs access to the true data,
> and is never given the keys.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 **NEW**     FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp