Re: securing and interposition (was RE: interposition requirements)

[Mark Little <mcl@arjuna.com>]

> It's not clear how a coordinator could be written to not register
> sub-participants per se.  It might refuse to register participants that
> don't present the appropriate credentials. It might refuse to accept
> enrollment messages that don't come piggy-backed on an application
response,
> but there's no inherent reason why such a response could not carry several
> enrollments - that's an issue for the carrier mapping. (ok - that would
need
> standardising).  But the coordinator state machine knows of only
> participants that wish to receive prepare, confirm , cancel and does not
> know where they fit in the application's view of the world.

Yes, and it shouldn't.

> To my surprise, I'm not sure this is quite as much of a problem in this
> case. C's attempt to register as a participant means only that it wants to
> be included in the vote and be told the outcome.  A may suspect/assume
that
> it is controlling resources that were affected by B (or by the messages
sent
> by the corresponding application elements), but A doesn't actually know,
or
> even care. Provided that a registration from the real controller of B's
> resources is accepted, the right things will happen to the resources.  The
> only threat from a spurious registration would seem to be denial of
> service - either delaying the vote or voting cancel.

Yes, but in certain circles that denial of service can be a very important
aspect. Until BTP X.Y comes along and actually has the time to address
security properly, this is going to have to be pushed up to the application,
or specific vendor implementations of BTP. However, interposition per se is
required for other, non-security reasons, so as I said in an earlier email,
supporting it from the start isn't going to break anything. Not supporting
it may well raise more objections than supporting it.

> (There are much bigger threats if any attacker can masquerade as the
> coordinator or an already registered participant - it is then possible to
> break atomicity, leading to probable loss or duplication of the
application
> work - easy money :-)

Agreed. Being devil's advocate, there's currently an implicit trust
relationship between participants and coordinator(s) anyway. Trusting the
root coordinator is one things, but a participant who pretends to be a
coordinator to its local sub-participants can get in the way of that trust.

Mark.

-----------------------------------------------------------------------
SENDER : Dr. Mark Little, Architect (Transactions), HP Arjuna Labs
PHONE  : +44 191 206 4538, FAX : +44 207 670 1964
EMAIL  : mark@arjuna.com