Re: 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).