Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support

[Buddhi Madhav <Buddhi.Madhav@veritas.com>]

Hi,

	Does this authentication scheme works?

1) Pass the encrypted password to qemu-kvm as follows:

# . /qemu-io --object secret,id=secmaster0,format=base64,file=key.b64 
       --object secret,id=password-secret,keyid=secmaster0,file=pw.aes,iv=$(<iv.b64)

2) QEMU process will decrypt the password. (call qcrypto_secret_lookup_as_utf8()).

3) For every disk open, QEMU process sends VM ID, vdisk ID, and decrypted password. Hyperscale server
   validates the password, and sends back the access token(unique 32bit ID).

4) Then for every I/O request QEMU process sends that token. Hyperscale server validates the
   token before allowing the access to the device.

Thanks
Madhav

On 12/13/16, 11:23 PM, "Stefan Hajnoczi" <stefanha@gmail.com> wrote:

    On Wed, Dec 14, 2016 at 12:06 AM, ashish mittal <ashmit602@gmail.com> wrote:
    > I am requesting feedback on the following design proposal for libqnio.
    >
    > This adds an access control mechanism between libqnio client and
    > server. It is not a full client-server authentication model, and it is
    > not intended to substitute an authentication mechanism.
    >
    > We wanted to check if the following would be acceptable for the first
    > version of VxHS patch while we design/implement a proper
    > authentication mechanism (possibly on a libqnio side branch)?
    >
    > 1.       Client passes VM ID and vdisk ID to the server when it wants
    > to open a vdisk.
    > 2.       Server verifies whether the client/VM has access to open the
    > disk and passes/fails the open request.
    
    Are the VM ID and vdisk ID secrets?
    
    If yes, then this is an authentication scheme.
    
    If no, then this is not secure and probably not worth doing.
    
    Stefan