> >> 2. In a managed direct migration workflow, an intermediary client brokers >> the connection between >> the source and destination. > > What do you mean by this? How is it brokered? Which part of the > conenction? > > Do you mean the non-P2P migration mode? (which is the only case where > the migration cookie wouldn't go directly from the source > libvirtd/virtqemud to the destination libvirt/virtqemud) That one is > secured by the connection transport mentioned above. > >> If the key is embedded within the migration cookie, this client gains >> full visibility into the secret, creating a significant attack surface >> within the system architecture. > > So IMO this point doesn't make sense either.
Hi Peter, thank you for the response! For the above, we indeed meant it for the non P2P migration mode, So since the 2 libvirts aren’t talking to each other in this case, the client, must inform the destination libvirt on what the PSK is, and in turn for that, the src libvirt must inform the client what the PSK is. I think all this would have been much easier, if the client controls the lifecycle of the PSK. Even outside this scenario, handing over the the PSK lifecycle management to the client provides greater flexibility and control over PSK parameters such as its key size, cryptographic algorithm, and rotation policies, which are indeed some aspects that clients may prefer to manage according to their own security requirements, similar to what happens right now in the x509 scenario. regards, tejus
