security draft removal of "Trust Models"

 

In doing the editing of the document to move the "Trust Models" concept
to an appendix, I'm using the following assumptions (significant editing
is being done to make these assumptions clean). Comments welcome:

 

-          The Remote Peer is generally "untrusted". 

-          The key issue remaining is whether local resources are shared
or unshared.

o        For cases where resource sharing can occur, there is two
categories - Streams where there is no "mutual trust", and Streams where
there is "mutual trust". For example, an iSCSI session with multiple
connections is an example of where streams share "mutual trust". A more
complex example might be a file server, where multiple streams to a
specific client might share mutual trust, but no client has mutual trust
with another client.  

 

In writing this up, I couldn't find an example where it helped to
further divide the definition to include remote and local - i.e. remote
mutual trust or local mutual trust. While theoretically possible, it
doesn't appear to apply for most protocols - and the document is already
long enough (~60 pages by the time it will be submitted). For example, a
file server may potentially have several Streams to a specific client
that share mutual trust, but there is no mutual trust between any single
collection of Streams which share mutual trust. 

 

Note that resource sharing can occur between streams which do not share
mutual trust - the two issues are independent. You can have/ have not
mutual trust between streams, and you can share/share not resources
between streams. For example, if there is no mutual trust between
Streams, then you should not expose the same STag to two streams because
one could invalidate the STag while the other is using it. However you
can share a common Untagged Receive Queue, as long as security
mitigations are in place.

 

 

Jim