Subject: [rddp] security doc - Definition of Trust

From: "Jim Pinkerton" <[email-masked]>
Date: Mon, 21 Jul 2003 10:44:11 -0700

One of the issues that has come up on the reflector is that the
definition of Trust should be changed to "Partial Trust", with an
appropriate change to the definition. The existing draft defines trust
as:

Trust - When one party depends upon the other party to not subvert the
goals of the protocols, e.g., it will not attempt to perform the
following attacks: spoofing, repudiation, information disclosure, denial
of service, or elevation of privilege. 

An Untrusted peer is a party that may (or may not) attempt to perform
one or more of the above attacks. A partially trusted peer (either the
Local Peer or Remote Peer) may be trusted to not attempt to perform some
subset of the above attacks, but not trusted to perform a different
subset.

Possible new definition (feedback/wordsmithing appreciated - I want
general agreement on this before I go through the spec):

Partial Trust - When one party depends upon the other party to not
attempt to perform a specific attack or set of attacks. A partially
trusted peer (either the Local Peer or Remote Peer) may be trusted to
not attempt to perform any subset of the specific list of attacks.
However, there is no guarantee that the Peer won't try to perform a
different set of attacks.

An Untrusted peer is a party that may (or may not) attempt to perform
one or more of the listed set of attacks. 

Jim

---

From: Caitlin Bester <[email-masked]>
Date: Mon, 21 Jul 2003 13:10:55 -0500

On Monday, July 21, 2003, at 12:44 PM, Jim Pinkerton wrote:

> definition of Trust should be changed to “Partial Trust”, with an 
> following attacks: spoofing, repudiation, information disclosure, 
> denial of service, or elevation of privilege.
>
> Local Peer or Remote Peer) may be trusted to not attempt to perform 
> some subset of the above attacks, but not trusted to perform a 
> different subset.
>
> Possible new definition (feedback/wordsmithing appreciated – I want 
> However, there is no guarantee that the Peer won’t try to perform a 

I believe there needs to be a distinction between "trust not to launch 
an explicit attack" and "trust to conform to the ULP".

To a large degree, the intent of the peer is irrelevant. The question 
is really relates to how paranoid must an application
be under what circumstances.

For example, while it will always be possible for the ULP to tailor 
tagged buffer exposure to *exactly* the degree required,
a local ULP could easily find this inconvenient to do. If may elect to 
enable an STag covering a set of buffers, and rely
upon its peer to only write to the portion that was enabled per the ULP.

However, it should not do so if it imperils any other process or any 
other party by doing so.

If you use a shared buffer pool for untagged messages, and the scope of 
that sharing encompasses DDP Streams with
multiple clients, then your trust of Client A should not place your 
interactions with Client B at risk (I would almost be
tempted to say MUST NOT).

Here is a very specific example where Client A may not be "attacking". 
Client A may merely be a bit over-eager and
sending the nTh request before receving the n-mth response and thereby 
has more than m requests pending.
These "cheating clients" have no intention of bringing the server down, 
but if there are enough of them they will
drain the shared buffer pool and eventually force another client's 
stream to be terminated (or possibly only
undergo a false drop). At that point they have damaged the other 
client, but there was never an intention to "attack".

Now just to be safe, it is probably worth stating that there are a set 
of known "attacks" which are automatically
considered to be "non-compliant" with the parent ULP. At least by 
default, the ULP could be something like
a hacker contest where you are *encouraged* to forge your address. But 
otherwise I think we are quite
safe stating that the type of attacks explicitly listed so far are 
presumed to be non-compliant with the ULP.

But the ultimate goal should be to make it clear that:

-- The local interface MUST provide tools to allow the ULP to protect 
itself.
-- The local ULP  MUST use these tools to enable its peer to perform as 
specified under the Upper Layer Protocol,
-- The local ULP MAY enable more access than what is required to 
simplify its use of the local interface, but
     SHOULD NOT do so if it imperils any other process or any other 
sessions.

But the need to protect yourself from stray bullets exists whether the 
shooter was aiming for you or not.

_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp