| Newsgroups |
gmane.ietf.rddp |
| Message-ID |
<[email protected]> |
Several clarifying comments:
> To summarize, the vulnerability occurs when an application trusts its
> remote peer to follow the upper layer protocol regarding STag access
> rather than using the local interface to enforce compliance.
>
> Or more generally, a buffer that the application intends to use is
> still exposed to update from non-authenticated DDP packets.
The latter is the better statement of the vulnerability, as it includes
man-in-the-middle traffic injection, e.g., via a connection hijack.
> David has proposed the ULP be able to rely on the availability
> of IPsec authentication of DDP packets.
Not exactly ... this was originally proposed in the RDDP security
draft, although with a "SHOULD implement" requirement that would have
to be changed to "MUST implement" in order to obtain IESG approval.
This was discussed in Seoul, which is why the original thread on
this topic carries the issue (4) tag from Seoul.
To the extent that I've pointed out that the IESG is very serious
about mandatory-to-implement security, I guess it's fair to tag me
with some responsibility for this proposal, BUT ...
... I have also posted that while IPsec is sufficient to deal with
this problem, it's more than is necessary. It should be possible
to design a mechanism that only authenticates the RDDP headers via
some sort of keyed cryptographic integrity check. I would ask
everyone to please stop looking for conspiracy theories about
how this is somehow part of a grand plot to require IPsec everywhere.
Despite this, I do think local functionality/interface modifications
(e.g., restrict all STags to be 'one-shot' and require implementations
to enforce this) are the preferred approach because they block not only
the man-in-the-middle but also the misbehaved or malicious client;
this is quite useful for protocols like NFS that generally cannot
place complete trust in clients. I probably should have said this
more strenuously about a dozen posts ago.
Caitlin's proposal below appears to be headed in a productive direction,
but at the end of the day, we have to abide by the IESG's "if you broke
it, provide tools to fix it" approach to mandatory-to-implement security
- if the WG wants its specifications to provide long-lived STag
functionality for use by protocols that are prepared to assume the
requisite high degree of trust among the communicating peers, the WG
is obligated to also provide the mandatory-to-implement security that
such protocols can use to prevent man-in-the-middle attacks on/via that
long-lived STag functionality. At the moment, I'm not certain whether
Caitlin's proposal is sufficient in this regard.
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 protected] Mobile: +1 (978) 394-7754
----------------------------------------------------
> -----Original Message-----
> From: Caitlin Bestler [mailto:[email protected]]
> Sent: Saturday, June 05, 2004 6:59 AM
> To: [email protected]; RDDP
> Subject: Re: [rddp] IPsec and RDDP as a transport
>
>
>
> On Jun 5, 2004, at 3:56 AM, [email protected] wrote:
>
> > Dwight,
> >
> >> Sorry to be dense, but I'm still having trouble visualizing the attack
> >> that makes DDP more vulnerable. I think it has been relegated to a man
> >> in the middle attack scenario, as bogus data from the real peer always
> >> gets through, even with IPSEC enabled. The transport layer behavior is
> >> the same with/without DDP headers; a packet with an appropriate
> >> transport sequence number gets ACKed and passed upstream to be placed
> >> in a buffer. The buffer eventually gets passed to the application.
> >
> > The difference happens here. If the STag is 'long-lived' or
'persistent'
> > and has not been invalidated, the buffer can still be modified remotely
> > *after* being passed to the application. Such modification is not
> > possible in the absence of DDP. If the STag is 'one-shot' (in whatever
> > sense that restriction is defined), the important property is that the
> > application can rely on the data not being changed by remote access
> > after the buffer has been passed to the application. If the WG
> > is prepared to restrict all STags to be 'one-shot' so that at the point
> > where the buffer is passed to the application, the STag used to deliver
> > the data MUST be invalid (and the RDDP implementation is responsible
> > for ensuring this), then it should be possible to avoid additional
> > security requirements in this area.
>
> To summarize, the vulnerability occurs when an application trusts its
> remote peer to follow the upper layer protocol regarding STag access
> rather than using the local interface to enforce compliance.
>
> Or more generally, a buffer that the application intends to use is still
> exposed to update from non-authenticated DDP packets.
>
> This is indeed a new security vulnerability, the question is how to
> deal with it.
>
> The current drafts take a "well we told you not to do that" approach.
> Personally, I still find this valid. But I will concede that others
> might consider this to be inadequate. But for the record I will
> point out that the RDDP layer simply cannot prevent the ULP from
> doing stupid things. Consider the fundamental rule that an exposed
> buffer is undefined *until* the ULP infers delivery from a untagged
> message or RDMA Read completion. An application that attempts to read
> smoke signals in partially update RDMA accessible buffers based
> only on tagged writes is very vulnerable not only to attack but to
> to unstable behavior. I doubt that anyone would propose requiring
> the RDDP layer to remove read access for the ULP on undelivered
> buffers that it has update access to. And the vulnerability
> to unstable behavior would be there even over IPsec.
>
> David has proposed the ULP be able to rely on the availability
> of IPsec authentication of DDP packets.
>
> I believe it would be more appropriate to require the local
> interface to provide adequate tools so that applications would
> neither be forced to overexpose buffers, or even be prone to
> do so by the defaults of the local interface. "Defaults" here
> would include omission of extra steps that an application
> *should* be taking, but the local interface requires additional
> steps to invoke.
>
> The proposed restriction to "one shot" STags would be one
> such local interface change, but I believe it is also to extreme.
>
> I believe we can determine what local interface requirements
> would be appropriate if we examine the current gaps:
>
> - The application can be encouraged to rely upon the remote
> peer to invalidate an STag when the transaction is done.
> If an expected remote invalidation is not performed, the
> application is typically required to invalidate the STag
> ifself. This is typically an asynchronous operation which
> would require the application to add an extra state before
> properly utilizing the buffer only after it had been secured.
>
> - Some applications advertise an aggregate buffer to be
> used over the span of several untagged messages. Each
> untagged message would indicate what portion of the
> advertised buffer had been used, and at the ULP layer
> pledge not to make further writes to that portion.
>
> Current local interfaces lack any support for enforcement
> of this model. When the portion used by the remote peer
> on each response is variably sized, there is no way for
> the Data Sink to remove one portion of a window without
> at least momentarily making the entire STag invalid.
>
> To address these problems I would propose the following
> local interface enhancements, which could be implemented
> as an alternative to authenticating DDP packets with IPsec
> or other equivalent transport-layer solutions:
>
> -- The local interface MUST provide an option where a posted
> receive operation will complete in error unless the Send
> successfully invalidated an STag.
>
> -- The local interface MUST provide an option where a posted
> receive operation will not complete until after a specified
> STag has been invalidated.
>
> -- The local interface MUST provide an option to rebind an
> STag to a contiguous subset of its current range without
> taking it through an intermediate invalid state.
>
> With these tools an application can easily ensure that the
> DDP exposure of an STag matches the ULP required exposure.
> Given the ability to easily remove a buffer's exposure *before*
> using it the application will face *no* additional security
> vulnerability and therefore would *not* require IPsec.
>
> That may also be true with a subset of the above. The last one
> is the only requirement that cannot be implemented by a shim
> layer over current verbs, and it is admittedly of the least
> generality.
>
>
>
>
> --
> Caitlin Bestler
> http://asomi.com/
>