--On 26 September 2011 08:35:34 +0200 Folkert van Heusden <[email protected]> wrote:
> Imho authentication only makes sense with encryption as well. I don't think this is true. Assume 2 computers, Server and Client, with both and the network between them under the same administrative control, which prevents snooping. This scenario does not really need encryption. It does, however, need authentication, or a non-root user on client could access any server resource simply by opening a socket. Equally, it is not hard to come up with scenarios where privacy of data is unimportant, but prevention of write access is important. Encryption adds little here. Personally I would advise avoiding reinventing the encryption wheel. For inbound encryption, we can (using stunnel or whatever) already use SSL to encrypt nbd sessions. Equally we can already use ipsec. Why do we need another method? For encryption of the data so it remains encrypted on the server, use dmcrypt on the client. I can see some form of challenge/response authentication might be useful; this would fit simply into an enhanced option negotiation scheme and thus could be carried out entirely in userspace. I would add that it is just as important to authenticate the server to the client as the (more obvious) authentication of the client to the server. So whatever we do should be symmetric. -- Alex Bligh ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
