RE: security doc - Definition of Trust

I see at least two issues brought up in this email:

 

1) I'm having problems grappling with the various levels of grayness on
what the intent of the remote peer is. I think there are many reasons
why a particular attack can occur, including:

 

      - bug in the implementation

      - lax coding in an application which runs in kernel space 

            which opens up security holes for other applications

      - unintentional attacks due to performance optimizations

      - unintentional attacks due to whatever...

      - intentional attacks

 

 

Personally, I don't see it worthwhile to put a lot of text throughout
the document saying all the reasons why a particular attack can occur -
the most important thing is that it did occur. How it occurred is
presumably highly implementation dependent, and thus not necessarily
appropriate for a security draft of a wire protocol.

 

In re-reading the security draft though, I realized I don't have this
type of statement in the introduction where Trust and Untrusted is
defined. Would it help if this was added?

 

Caitlin, could you make a suggestion on recommended text that I could
add to the paragraph below on "Untrusted" to point this out?

 

2) Adding of MUST and SHOULD text to the document. To date I've tried to
stay away from MUST and SHOULD normative text, and instead point out
issues, with recommended solutions. There is exactly one MUST statement
in the document:

 

*          All Non-Privileged Application interactions with the RNIC
Engine that could affect other applications MUST be done using the
Privileged Resource Manager as a proxy.

The rest of the document takes the approach that if you want this type
of a Trust Model, and care about this specific attack, it is RECOMMENDED
that you do this. I'm not clear on how to map your issues at the end of
the email below to this approach, or are you advocating a different
approach in the document? If so, could you outline it?

 

 

 

Jim

 

 

 

 

 

-----Original Message-----
From: Caitlin Bester [mailto:[email protected]] 
Sent: Monday, July 21, 2003 11:11 AM
To: Jim Pinkerton
Cc: [email protected]
Subject: Re: [rddp] 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.