Re: PS & Arch drafts: status and security issues

On Feb 19, 2004, at 2:51 PM, [email protected] wrote:

> I have news to report ...
>
> The IESG has been reviewing the RDDP Problem Statement and Architecture
> drafts.  The current draft status can be found in the IETF Draft 
> Tracker at
> 	https://datatracker.ietf.org/public/pidtracker.cgi
> Enter rddp in the WG Acronym: field and hit the SEARCH button.
>
> New versions of both drafts are going to be needed, mostly to deal with
> editorial issues, but some security issues have arisen in the 
> Architecture
> draft that I'm forwarding so that they can be discussed in the context
> of the security draft on the list and in Seoul:
>
> 	I see several threat issues.  The first is the tension between
> 	direct copy and packet authentication.  In many cases, it is not
> 	possible to authenticate a packet until the entire thing has been
> 	read.  But here, the data is being copied to a receiving buffer
> 	directly from the wire, before authentication takes place.  This
> 	is especially a challenge to a multi-threaded interface --- ATM
> 	where the cells for some packet are not consecutive, perhaps --
> 	where you might get interleaving.

This assumes that placement of non-authenticated data into a target
buffer represents a threat, but that is not the case.

The contents of the buffer are logically void until completion of
the trailing untagged message, by which time all of the packets
have been authenticated at the transport layer.

Authentication *above* the transport layer is unchanged. It is
done *after* the ULP accepts delivery of the message.

Now admittedly an application that ignores the rules and examines
the data while its contents are still undefined is leaving itself
open for an attack -- but that is true in general. The best encryption
in the world is worthless if you publish your private key on your
web site, or just leave it lying around in an unprotected file.

>
> The risk here is that if one does placement of fragments and then runs
> the (cryptographic) integrity check and the check fails, the 
> application
> has a corrupted buffer.  In particular, applications that are coded to 
> a
> sockets paradigm can get corrupted memory that was never part of any
> successful receive with RDDP - that can't happen with plain sockets.
>
> 	More generally, authorization for access to storage has to be
> 	dependent on the connection as well as the steering tag.  Otherwise,
> 	you introduce new vulnerabilities.  This is especially problematic
> 	given that receive buffers may (according to the document) be used
> 	for data from a different socket.

The spec makes it clear that the ULP is in control of enabling steering
tags for specific connections. Short of drafting a "local interface
requirements" document I don't see what else can be done.

In general 90% of the "security issues" related to RDMA can be 
summarized
as "the consumer may use the local interface in a manner which exposes
more memory access rights than is strictly required by the ULP."

But I believe that all of the local interfaces that have been discussed
or proposed do a fine job of closely matching the security needs of most
applications. (I still have problems with draft-hilland's lack of 
support
for multi-connection sessions, but the overwhelming majority of 
applications
use on a single active connection per session).

>
> 	Aside: I think that many of these issues, as well as the multiple
> 	receiver problem (and I do not accept the argument that requiring
> 	many different clients to use the same address is in any way
> 	comparable to any existing problem in that space), would go away
> 	if the steering tag sent over the wire to the receiver were not
> 	just opaque, but by intent a random 64- or 128-bit tag to a local
> 	buffer descriptor.  That permits easy local revocation of
> 	capabilities, as well as a defense against remote contamination
> 	attempts if the value were communicated previously over an
> 	encrypted channel.
>
> Also, if the STag values generated by an implementation are hard to
> predict, traffic injection by an adversary becomes more difficult.

If the STag has cryptographic value it will be too large for efficiency.

A statement could be added that STags SHOULD be chosen so as to minimize
the risk of bit-errors changing one valid STag into another valid STag.
But there is no way to make that a "MUST" -- how would you know how an
STag you have been given compares with other STags given to other 
clients?