RE: Removing Trust Models and including "Mutual Trust"

 

How about this to resolove the use of "Streams"??

 

Partial Mutual Trust - a collection of RDMAP/DDP Streams, which
represent the local and remote end points of the Stream, are willing to
assume that the Streams from the collection will not perform malicious
attacks against any of the Streams in the collection.

 

 

________________________________

From: [email protected] [mailto:[email protected]] On Behalf Of Jim
Pinkerton
Sent: Thursday, January 29, 2004 4:22 PM
To: Caitlin Bestler
Cc: [email protected]
Subject: RE: [rddp] Removing Trust Models and including "Mutual Trust"

 

 

I'm not trying to make any statement about ULP behavior - just RDDP
behavior. I.e. that the two ends of a Stream will not try to perform
malicious RDMAP/DDP attacks on each other. Thus "full compliance with
the ULP" would be out of scope (i.e. doesn't matter for this security
document).

 

On the use of "Streams", I used "Streams" as short hand - the sentence
now repeats the word multiple times - and the equivalent end point text
is "the Local and Remote Peer". I don't see any loss of clarity in using
Streams, and believe it to be more readable.

 

Separately, I got feedback to change the wording slightly to (change is
in bold, if it gets through the reflector):

 

 

Partial Mutual Trust - a collection of RDMAP/DDP Streams are willing to
assume that the Streams from the collection will not perform malicious
attacks against any of the Streams in the collection.

 

Would it make it clearer if I changed "malicious attacks" to "malicious
RDMAP/DDP attacks"?

 

 

 

Jim

 

 

 

> -----Original Message-----

> From: Caitlin Bestler [mailto:[email protected]]

> Sent: Thursday, January 29, 2004 12:58 PM

> To: Jim Pinkerton

> Cc: [email protected]

> Subject: Re: [rddp] Removing Trust Models and including "Mutual Trust"

> 

> 

> On Jan 29, 2004, at 12:24 PM, Jim Pinkerton wrote:

> 

> >

> >

> > Per the last IETF meeting, the Trust Model concept has now been
moved

> > to the Appendix. The document now focuses on whether a resource is

> > shared or not, and assumes the Remote Peer is untrusted. An

> > interesting side-effect of this is that the definition for "Partial

> > Trust" goes with it. And the document in general assumes the Remote

> > Peer (and Unprivileged Local Peer) are simply "untrusted".

> >

> >

> >

> > This semantic is unfortunately not rich enough, however. I've
started

> > editing the

> > document to more directly address security concerns in a
client/server

> > environment.

> > As part of that editing, it seems worthwhile to introduce a new

> > concept Sara Bitan

> > and I are calling "partial mutual trust" (Sara is now an author on
the

> > document,

> > specifically working on the Security Services for RDMAP/DDP
section).

> > This more

> > acurately describes the "session" concept that some applications
have.

> > And then

> > one can talk about how two Streams do not share "mutual trust" and

> > thus are subject

> > to a specific attack and need X countermeasure - so we can now
define

> > a server that

> > has multiple sessions (each with potentially multiple Streams) to

> > individual clients,

> > and individual clients do not trust each other.

> >

> >

> >

> > Feedback on this model would be appreciated.

> >

> >

> >

> > Here's my tentative definition of "partial mutual trust":

> >

> >

> >

> > Partial Mutual Trust - a collection of RDMAP/DDP Streams are willing

> > to assume that

> > the other Streams will not perform malicious attacks against any of

> > the Streams in

> > the collection.

> >

> >

> 

> 

> On a purely semantic basis I'm not sure I like assigning intent to the

> Streams,

> to the endpoints of the stream yes, but not the streams themselves.

> 

> Aside from that, is the intent here to distinguish between absence of

> malice

> from "full compliance with the ULP"? Where the latter would be Full

> Mutual Trust?

> ("Full compliance with the ULP" implies compliance with all *rules* of

> the

> ULP, not just the packet formats. Hence a properly filled out
withdrawal

> request with a forged signature is not truly "ULP compliant" even if
the

> syntax checks all pass because the packet is not submitted in
compliance

> with the full ULP).