Subject: [rddp] Security Draft issues

From: [email-masked]
Date: Mon, 30 Jun 2003 21:06:02 -0400

With my "I think I know something about security" hat on,
here are some comments on recent email concerning the security
draft.  All of these are for further discussion; nothing
in this message should be construed as instructions from
the WG chair.

-- Definition of Trust

        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.  

I think this definition might be usefully rewritten to be in
terms of partial trust (i.e., not to engage in specific attacks
that are listed each time the definition is used).  Complete Trust
is hard to achieve, and in some cases is essentially impossible
(e.g., operating systems do not exhibit complete Trust of
most applications) and the draft goes on to correctly say that
Privileged Applications are only partially trusted.  A useful
consequence of this would be a need to be explicit about the
threats of concern in the definitions of Local Trust and Remote
Trust in Section 5, which would help clarify that section.

It's also the case that Trust and Trusted (esp. capitalized) have
a well-understood meaning in some portions of the security
community that involves assurances about information leakage in
multi-level systems.  Most of the components we are talking about
here have no hope or intention of achieving that level of Trust,
and hence sticking to notions of partial trust is likely to be
clearer (yes, there are IETF folks who will read this as applying
to multi-level systems and ding us accordingly).

-- Protection Domain and Trust Model

   For those 
   Trust Models where resources are shared (Trust Models S-NT, S-LT and 
   S-T), it is recommended that Protection Domain be limited to the 
   number of Streams that share the same Trust Model.

I don't think that's what was intended.  Consider two applications on
the same system that use the same trust model (e.g. S-NT), but don't
trust each other (e.g., a web server and a file server).  Extending
the PD across all streams in both applications is clearly wrong.
In addition to "the same Trust Model", another important criterion
is "scope of mutual trust", which would prevent this.  I also agree
with the sense of the comment against this - if in doubt, use a smaller
protection domain, as Caitlin Bestler noted:

> I don't see the connection between Protection Domain scope
> and the Trust Models. My advice would simply be that a Protection
> Domain should be no wider than the ULP requires.

-- STag scope limits

Caitlin Bestler wrote:

> My reading of the DDP spec is that setting the Protection Domain
> is *the* way to control the scope of an STag.

I don't think so.  Section 10.3 of the DDP draft describes both
the Protection Domain and stream association mechanisms and then says:

   DDP MUST support 
   Protection Domain association and DDP stream association mechanisms 
   for associating an STag and a DDP Stream.  

IMHO, that implies that the functionality of using stream association
within a Protection Domain (as envisioned by the security draft) is
REQUIRED.  IIRC, this topic was discussed in Atlanta, but I'm not
going to object too strenuously to reopening it in the context of
the security draft; keep in mind that both models were felt to be
useful at the time.

-- Multiple STags, same buffer

> A distributed ULP that has chosen to be "trusting" (i.e. that it is
> only required to work when all participants follow the upper layer
> protocol) could easily have a buffer that is exposed to multiple
> participants. However, it would be the ULPs responsibility to ensure
> that at most one process was attempting to update the buffer at any
> time, and that nobody was trying to read it during an update.

There are two related partial trust models/assumptions that need to be
distinguished here:

- Client-Server partial trust, but no inter-Client trust.  A server
	accessed by independently authenticated users is an example.
	For example, Bob and Alice both trust the fileserver and v.v.,
	but Bob does not trust Alice and v.v.
- Client-Server + inter-Client partial trust.  An example is when
	all the clients are part of a single application that engages
	in things like barrier synchronization.

Sharing a buffer among multiple participants is only reasonable where
the partial trust in the "ULPs responsibility" is not just Client-Server,
but also Client-Client - the notion of "trusting" in the quoted text
appears to be assuming Client-Client partial trust (e.g., Alice and
Bob won't try to peek at each other's data, or there's no harm in them
doing so), which is not the general case.

Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

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

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 30 Jun 2003 20:52:08 -0500

>the security draft; keep in mind that both models were felt to be

Funny, I read that section as describing two different interfaces
to the same mechanism. Specifically:

>10.3 Association of an STag and a DDP Stream 
>
>   There are several mechanisms for associating an STag and a DDP 
>   Stream. Two reasonable mechanisms for this association are a 
>   Protection Domain (PD) association and a DDP Stream association. 
>
>   Under the Protection Domain (PD) association, a unique Protection 
>   Domain Identifier (PD ID) is created and used locally to associate 
>   an STag with a set of DDP Streams. Under this mechanism, the use of 
>   the STag is only permitted on the DDP Streams that have the same PD 
>   ID as the STag. For an incoming DDP Segment of a Tagged DDP Message 
>   on a DDP Stream, if the PD ID of the DDP Stream is not the same as 
>   the PD ID of the STag targeted by the Tagged DDP Message, then the 
>   DDP Segment is not placed and the DDP layer MUST surface a local 
>   error to the ULP. Note that the PD ID is locally defined, and cannot 
>   be directly manipulated by the Remote Peer. 
> 
>   Under the DDP Stream association, a DDP Stream is identified locally 
>   by a unique DDP Stream identifier (ID).
>
Which is really the same thing as a Protection Domain Identifier, except
that the Consumer does not have to generate it.

>   An STag is associated with a 
>   DDP Stream by using a DDP Stream ID. In this case, for an incoming 
>   DDP Segment of a Tagged DDP Message on a DDP Stream, if the DDP 
>   Stream ID of the DDP Stream is not the same as the DDP Stream ID of 
>   the STag targeted by the Tagged DDP Message, then the DDP Segment is 
>   not placed and the DDP layer MUST surface a local error to the ULP. 
>   Note that the DDP Stream ID is locally defined, and cannot be 
>   directly manipulated by the Remote Peer. 
>
So that in either case the "Protection Identifier" of the DDP Stream
is compared with the STag's "Protection Identifier".

>   A ULP SHOULD associate an STag and a DDP Stream. DDP MUST support 
>   Protection Domain association and DDP Stream association mechanisms 

And *nowhere* does it imply that a single DDP Stream needs to be
associated with *two* "Protection Identifiers", or that an STag
ever has to be associated with *two* "Protection Identifiers".

In any event, I interpreted the security-draft text as specifically
implying that you could have both methods active on the *same* stream
or the same STag.

My interpretation of the "DDP Stream ID" was to the effect of "each
DDP Stream should have a default Protection ID that is unique to it
and will be used if the ULP does not explicitly assign it to a
Protection Domain."

Personally, I'm working on a software implementation, so a quick OR
that isn't going to make that much difference in performance, especially
if optimizated tso that the matching id more often the first one. But
if that was meant to imply checking two values then it clearly needs
to be reworded.

But my recomendation is for a single check. It's simple. It's quick,
and its adequate.

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 30 Jun 2003 21:14:28 -0500

>doing so), which is not the general case.

Agreed. This is a better wording of the point I was trying to raise
about what impact there would be if the remote ULP did not follow the
rules. Phrased as above it makes it clear that just because *you*
trust the peer to follow the rules does not necessarily mean that
you should make that decision on behalf of the *other* clients.

One level out from that, you should not extend that trust on behalf
of other programs running on the same host. So you should *never*
be so trusting that you can be tricked into violating system security.
Basically, if you're running with root privileges, you shouldn't
trust anybody or anything external unless you are the *sole*
application running on the machine. And even then I wouldn't
recomend it.