Re: security doc - Definition of Trust

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

>  
>
> 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
>


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.