On 5 Dec 2014, at 16:30, Sam Skipsey <[log in to unmask]> wrote:
> As requested in the meeting, here's a presentation-format discussion
> of non-Grid-Proxy mechanisms as an idea. (I think Andy and I were
> talking across purposes for some of our disagreement, so hopefully
> this clarifies the position.)
The central problem is how a third party service like a storage server can trust that a particular job is acting on behalf of a user. This always requires either giving a secret to the job (e.g. a password, or a proxy in a sandbox) or doing something equivalent to proper proxy delegation in which the private keys never go over the network.
As I said during the meeting, the problem with your model is that the signature of the job becomes a replayable secret like a password.
This means that I have to keep the signature and job a secret, otherwise people can do malicious versions of the transaction(s) allowed by my signature using their own clients. But the job must reveal this secret signature to the services it wants to talk to. The strength of proxies is that there is a secret which never needs to be disclosed or go over the network, and a signature component (the proxy certificate chain) which can safely be disclosed to anyone.
Furthermore, I don’t really buy your answer to minimise the scope of replay attacks on slide 19 that asserts “well written code will always know which files it will need before execution, and which files it expects to produce when complete. We can therefore map these to a series of Transactions: Source -> Destination”. Pilot jobs are so successful because they allow late binding, and moving to event servers pushes that binding even later. We want jobs to have more flexibility not less about what they do when they land on a worker node in response to the available cores, memory, network conditions, and what has already been processed.
Cheers
Andrew
--
Dr Andrew McNab, High Energy Physics,
University of Manchester, UK, M13 9PL.
Skype and Google Talk: andrew.mcnab.uk
Web: www.hep.manchester.ac.uk/u/mcnab
|