TBTF: security considerations proposed text

TBTF'ers,

Henrik and I took an AI to draft langauge for the
various security considerations sections in our
specs (see below). We've worked it to a point
that we believe we should bring this to the TBTF for
consideration.

We welcome your comments.

Cheers,

Henrik & Chris

* * * * *

Part 1

SOAP Security Considerations (new section in part 1)

The SOAP Framework does not directly provide any mechanisms for dealing
with access control, confidentiality, integrity and non-repudiation.
Such mechanisms can either be provided as SOAP modules using the SOAP
extensibility model or through features expressed within the underlying
protocol and made available to SOAP applications through the SOAP
binding framework. This section describes the security considerations
that designers and implementers should take into consideration when
designing and using such mechanisms.

As always, SOAP implementers should be aware of rogue SOAP applications
sending intentionally malicious data to a SOAP node. Similarly, SOAP
nodes should be aware of the implications of sending data to other SOAP
nodes in case those nodes are malicious. It is strongly recommended that
a SOAP node receiving a SOAP message is capable of evaluating to what
level it can trust the sender of that SOAP message and its contents.
Likewise, any SOAP node sending a SOAP message to another SOAP node
should be capable of evaluating to what level it can trust the receiving
SOAP node to process the message responsibly. This applies not only to
ultimate recipients but also SOAP intermediaries.

SOAP Nodes

SOAP can carry application-defined data as SOAP header blocks or as SOAP
body contents. Header blocks are identified by the local name and
namespace identifier of the outer-most element information item of that
block. Processing a SOAP header block may include dealing with side
effects such as state changes, logging of information, or the generation
of additional messages. It is strongly recommended that only
well-defined header blocks with known security implications of any side
effects be processed by a SOAP node.

The SOAP body consists of zero or more namespace qualified element
information items located as the immediate children of the Body element
information item. As for SOAP header blocks, processing a SOAP body may
imply the occurrence of side affects that may, if not properly
understood, have severe consequences for the receiving SOAP node. As for
SOAP header blocks, it is strongly recommended that only well-defined
body contents with known security implications be processed.

Security considerations, however, are not just limited to recognizing
the immediate child elements of the SOAP header and the SOAP body.
Implementers should pay special attention to the security implications
of all data carried within a SOAP message that can cause the remote
execution of any actions in the recipient's environment. This includes
not only data expressed in XML but data that may be encoded as binary
data or carried as parameters like for example URI query strings. Before
accepting data of any type, an application should be aware of the
particular security implications associated with that data within the
context it is being used.

SOAP implementers should be careful to ensure that if processing of the
various parts of a SOAP message is provided through modular software
architecture, that each module is aware of the overall SOAP security
context. For example, a SOAP body should not be processed without
knowing the SOAP context in which it was received.

SOAP Intermediaries

SOAP inherently provides a distributed processing model that may involve
a SOAP message passing through multiple SOAP nodes. As is the case for
any type of intermediary, SOAP intermediaries are by definition
men-in-the-middle, and represent an opportunity for man-in-the-middle
attacks. Security breaches on systems that run SOAP intermediaries can
result in serious security and privacy problems. A compromised SOAP
intermediary, or an intermediary implemented or configured without
regard to security and privacy considerations, might be used in the
commission of a wide range of potential attacks.

In analyzing the security implications of potential SOAP related
security problems, it is important to realize that the scope of security
mechanisms provided by the underlying protocol may not be the same scope
as the whole message path of the SOAP message. There is no requirement
in SOAP that all hops between participating SOAP nodes use the same
underlying protocol and even if this was the case, the very use of SOAP
intermediaries is likely to reach beyond the scope of transport-level
security.



5.5 Security Considerations (replaces ed note)

      The effects on security of not implementing a MUST or
      SHOULD, or doing something the specification says MUST NOT or SHOULD
      NOT be done may be very subtle. Binding specification authors should
      describe, in detail, the security implications of not following
      recommendations or requirements as most implementors will not have
      had the benefit of the experience and discussion that produced the
      specification.

      In addition, a binding specification may not address or provide
      countermeasures for all aspects of the inherent security risks.
      The binding specification authors should identify any such risks
      as might remain and indicate where further countermeasures would
      be needed above and beyond those provided for in the binding
      specification.

      Binding specification authors should be aware that SOAP extension modules
      expressed as SOAP header blocks may affect the underlying protocol
      in unforeseen ways. It is strongly recommended that a binding
      specification should describe any such interactions. For example,
      a SOAP message carried over a particular protocol binding may
      result in seemingly conflicting features such as might be the case with HTTP
      basic auth combined with a SOAP based authentication mechanism.

Part 2

8.6 Security Considerations (new sub-section in HTTP binding)

      The SOAP HTTP binding described in section 8 can be considered as
      an extension of the HTTP application protocol. As such, all of the
      security considerations identified and described in section 15 of
      the HTTP specification[2] apply to the SOAP HTTP binding in
      addition to those described in Part 1[1] of the SOAP specification
      in section 4.x. Implementers of the SOAP HTTP binding SHOULD
      carefully review this material.

Received on Monday, 4 February 2002 16:21:39 UTC