On 8 Dec 2014, at 14:01, Sam Skipsey <[log in to unmask]> wrote:
> On 8 December 2014 at 13:26, Andrew McNab <[log in to unmask]> wrote:
>> On 8 Dec 2014, at 10:55, Sam Skipsey <[log in to unmask]> wrote:
>>> On 5 December 2014 at 19:25, Andrew McNab <[log in to unmask]> wrote:
>>>> 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.
>>>
>>> No, it doesn't (or rather, "replayable secrets" are pretty much a
>>> solved problem - you just embed a sequence number into the secret to
>>> prevent it being replayed, and then you just have to save a sequence
>>> number, which is less effort than your strawman below).
>>
>> Trying to patch the inherent replay-ability of signed jobs with things like sequence numbers means you have to go further and further in the direction of deciding what service instances you’re going to be talking to before submitting the job. That makes it harder and harder to build resilient systems that can cope with changing patterns of load at different places, and operations that fail and need retrying. With another pre-created signature and sequence number somehow? That the storage at some other site has to keep track of too somehow? How do you differentiate between a failover to another storage site and a malicious replay? Some protocol for storage sites to talk to each other about this in the background? In big distributed systems like ours this gets very complicated very quickly.
>
> But also, it's not a serious problem for read requests for WLCG VOs
> (and write requests, if allowed to be idempotent, reduce to a race
> condition, and then can't be replayed).
Seriously though, how would you deal with the failover use case for instance?
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
|