securing and interposition (was RE: interposition requirements)

[Peter Furniss <peter.furniss@choreology.com>]

(pruned back the cc list)

I've changed the title to distinguish this aspect from the more general. As
was said at the London f2f, security and two-phase commit is not a simple
addition of the two mechanisms that can be both be used to (roughly
speaking) enhance an application exchange - the two interact, and have to be
considered together.



interspersed comments below



To do this properly is almost certainly beyond the scope of
> -----Original Message-----
> From: Bill Pope [mailto:bpope@bowstreet.com]
> Sent: 02 May 2001 20:53
> To: 'Alastair Green'; Mark Little
> Cc: Sazi Temel; bt models
> Subject: RE: interposition requirements
>
>
>
> Hello Alastair,
> You seem to have caught up quickly.
>
> I agree, some of the points are a bit dissonant :^).  I believe that we
> are coming to the conclusion you would prefer but will rise to your
> bait on some of the points below because I think they will frame
> subsequent discussion and direction.
>
> Let me preface this with my assumption that interoperability of
> implemenations is a requirement.
>
> A standard that does not define how the components being addressed
> interact is not a standard, or is at best a poorly specified
> standard. What is being discussed here is not an implementation
> optimization but a part of the standard which directly addresses
> permitted and expected communications between two of the constituent
> pieces.  If a coordinator state machine is written to the expectation
> that sub-participants will not register with the coordinator it will
> not work with sub-participants that exhibit this behaviour.

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.

> The point made during the face-to-face was that even with a Trust 3
> model the coordinator has no previous context with the registering
> sub-participant and so has no basis for establishing trust.

Not disagreeing your recollection of what was said, but point of Trust 3
(and indeed any serious consideration of the 2pc+security combination) is
precisely that there must be more context passed around than just the simple
address of the  coordinator and a transaction identity. There have to be
appropriate credentials so that a secure coordinator DOES know that the
would-be participant has the right to register.  But this is a complex
story, which we aren;t going to get sorted out by the end of July.

>                             There
> is a relationship between the participant provider and the
> sub-participant but this relationship is not known by the root
> coordinator.  This type of intermediated relationship leads to what is
> referred to as transitive trust, in which A trusts B and B referred C
> to A so C is alright with A too.  There has been little work done on
> how much of the relationship between B and C is expressable and so
> knowable back at A.

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.

(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 that for Trust 1 relationships registration of a
> sub-participant with a higher level coordinator works perfectly well.
> What I would like to see in the spec is some indications and
> counter-indications for use of both registration models.
>
> Some more in-line below.
>
> Regards,
> =bill
>
> > -----Original Message-----
> > From: Alastair Green [mailto:alastair.green@choreology.com]
> > Sent: Wednesday, May 02, 2001 12:35 PM
> > To: Mark Little
> > Cc: Sazi Temel; Bill Pope; bt models
> > Subject: Re: interposition requirements
> >
> >
> > I've just got back from holiday, and it's taken me a while to
> > review this thread. I hope you won't mind me coming in on it late
> > with a few points, which are perhaps dissonant.
> >
> > a) A standard should not restrict the optimization choices of
> > an implementor, nor the deployment choices of an end-user, unless
> > there is a _functional_ need (where "functional" means " in order to
> > fulfil a requirement").
> >
> > b) The first requirement here is "allow participants to be
> > enrolled with a coordinator so that they can vote and know the
> > outcome".  Fulfilling this requirement does not require any
> > restriction on who can enrol with whom.
> >
> > c) There may be an addition to the basic requirement: ", and to
> > ensure that participants and coordinators trust each other".
> >
> > [This is not a trivial addition by any means, and I believe
> > it should not be approached in a piecemeal fashion. In the models
> > sub-committee face-to-face in London I expressed the view that a
> > secure business transaction protocol was a very desirable thing, but
> > that the time scale for this current effort should make all
> > considerations of security out of scope. I still hold to that
> > opinion.
> > If in the future we have an OASIS BTP 2.0 I think I would argue for
> > the secure version to be an optional part of the spec.]
> >
> > d) There are three ways of ensuring trust between the BTP
> > actors. The first (Trust 1) is to put them all on a sealed network,
> > where all messages are deemed to be trusted ("behind the firewall",
> > a VPN). The second (Trust 2) is a variant of the first: to tunnel
> > all or some protocol messages through other messages which are
> > already trusted (x.com only trusts the contents of messages sent on
> > a special BTP-aware link or session to y.com, but requires no
> > further reassurance). The third (Trust 3) is to authenticate all
> > actors, and then sign all messages between them, so that every
> > message has unfalsifiable distinguished endpoints, tamper-proof
> > contents, and cannot be repudiated ("do it properly").
>
> Trust 2 is not a variant of Trust 1.  It uses a specific context to
> extend trust in a specific area.  A client logs onto a server.  The
> server determines a list of entitlements based on the identity (this
> is close enough for discussion purposes).  Very different from
> "everyone behind the firewall is trusted" regardless of the operation
> being performed.  Trust 2 is what is powering the Internet today. The
> trust assurances vary according to the risk each party is willing to
> take.  Access to a forum may be base on only having a valid email
> address.  Access to goods and services is most often based on having a
> valid credit card number.  Access to corporate resources is most often
> based on having an off-line verified business relationship.

The view of Trust 2 as a variant of Trust 1 came from viewing the trusted
path as equivalent to a VPN connection - if you read the first part of your
paragraph as referring to a VPN logon, it fits.  The key thing is that it is
connection-based. Two-phase commit, if you include the recovery mechanisms
(essential), is not really connection-based. Whatever assurance you had on
the first connection (on which the application messages were sent, be it
assumed) does not apply on a recovery connection, which has the power to
determine whether the application messages are confirmed or cancelled
(unless of course you re-establish the authentication - but that's really
Trust 3)


> > e) Making rules about who can register with whom in order to enforce
> > performance, is not our business with our standards hats on (so long
> > as we don't _mandate_ the noxiously unperformant). Making such rules
> > to enforce aspects of security is not possible without establishing
> > a trust framework.
>
> Making such rules to enforce aspects of security is not possible
> without establishing a trust framework OR using a pre-existing trust
> framework.  In a B2B relationship there is some expectation of, well,
> a relationship.  This can be manifested by granting an account,
> exchanging certs, sending a URL, or what ever is appropriate to the
> relationship.
>
> > [We obviously can't mandate Trust 1. We could try to shoehorn
> > BTP protocol messages onto authenticated application messages (Trust
> > 2), but that would require some nice judgements about how much trust
> > to mandate/recognize, or would be infeasible, depending on how much
> > of the protocol you want to secure -- just enrollment or the full
> > 2PC that follows. In the latter case there may not be enough
> > application messages to support the voting/outcome protocol, or we
> > have just reinvented Trust 1. The only way to properly restrict
> > message passing is to use Trust 3. That implies that all actors (app
> > and protocol engine) have authenticated identities etc. Are we
> > really up for that and all it implies? I doubt it, and I also would
> > strongly oppose mandating such an elaborate framework in a nascent
> > field.]
>
> Agreed, Trust 3 has been successful only within limited communities
> like PGP mail or hub and spoke business relationships.  It mandates an
> infrastructure that is not widely deployed.  However I do think that a
> Trust 2 model bears closer examination before being discounted.  In
> particular looking at the trust boundries and actor relationships to
> see if there is some expressable set of expectations.
> I strongly agree with your point not to mandate an impediment to
> adoption.
>
> > f) Both the coordinator and the participant might have legitimate
> > reasons to restrict enrollment (refuse to do business with the other
> > party).
>
> Agreed.
>
> > g) The role "sub-coordinator" is a convenient term for a participant
> > which chooses to act as a coordinator to other participants. It is
> > not a distinct actor, because its behaviour can be fully described
> > in terms of two existing actors: P and C.
>
> Correct in the abstract but I would not have wanted to attempt this
> discussion without being able to use the term.  Similarly I would not
> want to describe these interactions to the eventual implementors
> without access to the term.
>
>
> > Alastair
> >
> > Mark Little wrote:
> >
> > > > We can always define and disallow it per definition but
> > it looks like an
> > > > artificial restriction... because a service can always go
> > around it by
> > > > starting its own transaction under the cover and the main
> > coordinator
> > > > cannot do anything, cannot even aware of this new transaction.
> > >
> > > The default should be that it interposition is available
> > from a participant
> > > then it should be used. However, I've nothing against it being a
> > > configurable option as long as it is up to the participant
> > to decide whether
> > > it wants to allow it to be turned off.
> > >
> > > Mark.
> > >
> > > ----------------------------------------------
> > > Dr. Mark Little (mark@arjuna.com)
> > > Transactions Architect, HP Arjuna Labs
> > > Phone +44 191 2064538
> > > Fax   +44 191 2064203
> >
>