- From: Marc Hadley via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 20 Jul 2005 18:21:36 +0000
- To: public-ws-addressing-eds@w3.org
Update of /sources/public/2004/ws/addressing
In directory hutz:/tmp/cvs-serv24841
Modified Files:
ws-addr-soap.xml ws-addr-core.xml
Log Message:
Added resolution to issues lc55 and lc87 - reworked security section
Index: ws-addr-core.xml
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-core.xml,v
retrieving revision 1.105
retrieving revision 1.106
diff -C2 -d -r1.105 -r1.106
*** ws-addr-core.xml 19 Jul 2005 19:13:52 -0000 1.105
--- ws-addr-core.xml 20 Jul 2005 18:21:34 -0000 1.106
***************
*** 452,466 ****
<p>This section defines the information model and syntax of message addressing
properties.</p>
- <note>
- <p> The Working Group requests feedback regarding the mechanism for and description
- of Message Addressing Property extensibility beyond the MEPs currently described
- in the WSDL specifications, along with use cases that illustrate how referencing
- specifications and other users of Addressing intend to extend them. Although the
- Working Group has resolved upon a <loc
- href="http://www.w3.org/2002/ws/addr/wd-issues/#i054">particular
- design</loc>, some participants believe it is not adequately specified. Such
- feedback will help the Working Group determine whether it needs to re-examine
- this issue. </p>
- </note>
<p> Message addressing properties provide references for the endpoints involved in an
interaction. The use of these properties to support specific interactions is in
--- 452,455 ----
***************
*** 835,865 ****
</div2>
</div1>
<div1 id="securityconsiderations">
<head>Security Considerations</head>
! <p>Users of WS-Addressing and EPRs (i.e., entities creating and receiving Message
! Addressing Properties and EPRs) SHOULD only use EPRs from sources they trust. For
! example, such users might rely on the presence of a verifiable signature by a
! trusted party over the EPR, or an out-of-band means of establishing trust, to
! determine whether they should use a particular EPR.</p>
! <p>EPRs and message addressing properties SHOULD be integrity-protected to prevent
! tampering. Such optional integrity protection might be provided by the transport, a
! message level signature, or use of an XML digital signature within EPRs.</p>
! <p>To prevent information disclosure, EPR issuers SHOULD NOT put sensitive information
! into the [address] or [reference parameters] properties.</p>
! <p>Some processors may use message identifiers ([message id]) as part of a uniqueness
! metric in order to detect replays of messages. In this case, care should be taken to
! ensure that for purposes of replay detection, the message identifier is combined
! with other data, such as a timestamp, so that a legitimate retransmission of the
! message is not confused with a replay attack. It is also advisable to use message
! identifiers that are not predictable, to prevent attackers from constructing and
! sending an unsolicited reply to a message without having to see the actual message.</p>
! <p>When [reply endpoint] and/or [fault endpoint] do not contain the anonymous URI, the
! processor of such an EPR should take care to avoid a denial of service attack caused
! by opening an excessive number network connections, which are typically a scarce
! resource.</p>
! <p>Care should be taken to avoid participating in a denial of service attack in which an
! attacker sends messages to many receivers and includes a [reply endpoint] or [fault
! endpoint] for the target of the attack.</p>
</div1>
<div1 id="references">
<head>References</head>
--- 824,885 ----
</div2>
</div1>
+
<div1 id="securityconsiderations">
<head>Security Considerations</head>
!
! <p>Conformance to this specification does not require a message receiver to honor the
! WS-Addressing constructs within a message if the receiver is not satisfied that the
! message is safe to process.</p>
!
! <p>WS-Addressing supports capabilities that allow a message sender to instruct a message
! receiver to send additional unsolicited messages to other receivers of their choice.
! To an extent the content of such unsolicted messages can also be controlled using
! reference parameters supplied by the initial message sender. Because of these
! capabilities it is essential that communications using WS-Addressing are adequately
! secured and that a sufficient level of trust is established between the communicating
! parties before a receiver processes WS-Addressing constructs within a message. There
! are several aspects to securing a message: </p>
!
! <olist>
! <item><p>EPRs and message addressing properties should be integrity-protected to prevent
! tampering. Such integrity protection might be provided by the transport, a message
! level signature, or use of an XML digital signature within EPRs.</p></item>
! <item><p>Users of EPRs should validate the trustworthiness of an EPR before using it by
! considering the following aspects:</p>
! <olist>
! <item><p>whether the EPR was obtained from a trusted source</p></item>
! <item><p>whether the EPR was obtained from a source with authority to represent the [address] of that EPR</p></item>
! <item><p>whether the [address] of the EPR is a trusted destination</p></item>
! </olist>
! </item>
! </olist>
!
! <p>For example, the receiver of a message might rely on the presence of a verifiable signature
! by a trusted party over the message addressing properties to determine that the message
! originated from a trusted source and further require that the [reply endpoint] and
! [fault endpoint] are signed by a principle with authority to represent the [address] of
! those EPRs to ensure that unsolicted messages are not sent. Alternatively an out-of-band
! means of establishing trust might be used to determine whether a particular EPR is
! trustworthy.</p>
!
! <div2>
! <head>Additional Security Considerations</head>
!
! <p>To prevent information disclosure, EPR issuers should not put sensitive information
! into the [address] or [reference parameters] properties unless it has been
! adequately protected against arbitrary
! disclosure.</p>
!
! <p>Some processors may use [message id] as part of a uniqueness metric in order to
! detect message replay. Care should be taken to ensure that, for purposes of
! replay detection, [message id] is composed from data, such as a timestamp,
! such that a legitimate retransmission of the message is not confused with a
! replay attack. It is also advisable to use a [message id] that is not
! predictable, to prevent attackers from constructing and sending an unsolicited
! reply to a message without having to see the actual message.</p>
! </div2>
!
</div1>
+
<div1 id="references">
<head>References</head>
***************
*** 868,877 ****
href="&w3c-designation-wsa-soap;">
<titleref>&wsa-soap.title;</titleref>, M. Gudgin, M. Hadley, Editors.</bibl>
- <!--
- <bibl key="WS-Addressing-WSDL" id="WSADDR-WSDL"
- href="&w3c-designation-wsa-wsdl;">
- <titleref>&wsa-wsdl.title;</titleref>, M. Gudgin, M. Hadley, Editors.</bibl>
- *** For LC drafts only ***
- -->
<bibl key="WS-Addressing-WSDL" id="WSADDR-WSDL"
href="http://www.w3.org/TR/2005/WD-ws-addr-wsdl-20050215">
--- 888,891 ----
Index: ws-addr-soap.xml
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-soap.xml,v
retrieving revision 1.84
retrieving revision 1.85
diff -C2 -d -r1.84 -r1.85
*** ws-addr-soap.xml 20 Jul 2005 15:53:22 -0000 1.84
--- ws-addr-soap.xml 20 Jul 2005 18:21:34 -0000 1.85
***************
*** 806,826 ****
<div1 id="securityconsiderations">
<head>Security Considerations</head>
! <p>WS-Addressing message addressing properties serialized as SOAP headers (wsa:To, wsa:Action
! et al.) including those headers present as a result of the [reference parameters] property
! SHOULD be integrity protected as explained in &wsa-core.title;[<bibref ref="WSADDR-CORE"
! />].</p>
! <p>When receiving a SOAP message, certain SOAP headers may be resulting from the serialization
! of an EPR's [reference parameters] property. The SOAP message receiver can perform
! additional security and sanity checks to prevent unintended actions.</p>
! <div2 id="intseccons">
<head>Additional Considerations for SOAP Intermediaries</head>
! <p>To avoid breaking signatures, intermediaries MUST NOT change the XML representation of
! WS-Addressing headers when relaying those headers. Specifically, intermediaries MUST NOT
! remove XML content that explicitly indicates otherwise-implied content, and intermediaries
! MUST NOT insert XML content to make implied values explicit. For instance, if a
! RelationshipType attribute is present with a value of <attval>&nsuri;/reply</attval>,
! an intermediary MUST NOT remove it; similarly, if there is no RelationshipType attribute,
! an intermediary MUST NOT add one. </p>
</div2>
</div1>
<div1 id="conformance">
--- 806,904 ----
<div1 id="securityconsiderations">
<head>Security Considerations</head>
!
! <note><p>No assumptions are made herein of the application level security
! requirement, the organization of the application, implementation of senders
! or receivers, or of the ways that other protocols may make use of
! WS-Addressing, and what security mechanisms they may employ. A holistic
! approach to security which considers all components of the application,
! other protocols utilized, the way that these protocols compose with
! WS-Security, and the use of other methods or additional techniques is highly
! recommended.</p></note>
!
! <p>As discussed in &wsa-core.title;[<bibref ref="WSADDR-CORE"/>],
! WS-Addressing supports capabilities that allow a message sender to
! instruct a message receiver to send additional unsolicited messages to
! other receivers of their choice and to control the contents of those
! messages to an extent using reference parameters. The SOAP binding of
! WS-Addressing transforms EPR reference parameters into SOAP headers and
! this allows a message sender to request a message receiver to send
! additional unsolicited SOAP messages to other receivers of their choice
! and to specify a set of SOAP headers that must be included in such
! messages.</p>
!
! <p>SOAP headers are a powerful extension mechanism and therefore great care
! should be taken before honoring a [reply endopoint] or [fault endpoint]
! to avoid inadvertant participation in the activities of malicious SOAP
! message senders.</p>
!
! <p>WS-Addressing message addressing properties serialized as SOAP headers
! (wsa:To, wsa:Action et al.) including those headers present as a result
! of the [reference parameters] property should be integrity protected as
! explained in &wsa-core.title;[<bibref ref="WSADDR-CORE"/>].</p>
!
! <p>Messages that use wsa:ReplyTo or wsa:FaultTo headers whose [address] is
! not the predefined anonymous URI should include claims that allow a
! receiver to confirm that the EPR was issued by a principle with
! authority to represent the [address] of the EPR.</p>
!
! <p>When receiving a SOAP message, certain SOAP headers may have resulted
! from the serialization of an EPR's [reference parameters] property. A
! SOAP message receiver should perform additional security and sanity
! checks to prevent unintended actions.</p>
!
! <div2>
! <head>Establishing EPR Trust</head>
!
! <p>There are many mechanisms that could be used to supply proof that a
! message sender has authority to represent the [address] of EPRs supplied
! within the message. Typically such mechanisms require the inclusion of a
! WS-Security[<bibref ref="WS-Security"/>] header that contains XML digital signatures
! binding the wsa:ReplyTo and wsa:FaultTo elements to the SOAP message
! using a security token issued by an authority trusted by the receiver of
! the message for the domain of the [address] of the EPR. Possession of a
! security token issued by a trusted authority for the domain of the
! [address] of the EPR provides a level of confidence that the message
! sender has authority to represent the [address].</p>
!
! <p>For example, a message could include a WS-Security[<bibref ref="WS-Security"/>] header
! that contains XML digital signatures binding the wsa:ReplyTo and
! wsa:FaultTo elements to the SOAP message using an X.509 certificate for
! the domain addressed by the [address] of the EPR. If the certificate is
! issued by a certificate authority trusted by the receiver of the message
! then the receiver can can have some level of confidence that the message
! sender has authority to represent the [address] of the EPR.</p>
!
! </div2>
!
! <div2>
! <head>Additional Security Considerations</head>
!
! <p>The wsa:isReferenceParameter attribute is only meaningful on SOAP
! headers. Message processors should consider its appearance elsewhere in
! a SOAP message as a possible attack.</p>
!
! <p>Message processors should consider elements from the soap11, soap12 and
! wsa namespaces appearing as reference parameters in an EPR as a possible
! attack.</p>
!
! <p>There are known XML ID and re-structuring attacks which should be
! considered by message processors, see [<bibref ref="WS-Security"/>] - Security
! Conciderations: Removal and modification of XML elements.</p>
! </div2>
!
! <div2>
<head>Additional Considerations for SOAP Intermediaries</head>
!
! <p>To avoid breaking signatures, intermediaries MUST NOT change the XML
! representation of WS-Addressing headers when relaying those headers.
! Specifically, intermediaries MUST NOT remove XML content that explicitly
! indicates otherwise-implied content, and intermediaries MUST NOT insert
! XML content to make implied values explicit. For instance, if a
! RelationshipType attribute is present with a value of
! <attval>&nsuri;/reply</attval>, an intermediary MUST NOT
! remove it; similarly, if there is no RelationshipType attribute, an
! intermediary MUST NOT add one.</p>
</div2>
+
</div1>
<div1 id="conformance">
***************
*** 851,860 ****
<bibl key="WS-Addressing-Core" id="WSADDR-CORE" href="&w3c-designation-wsa-core;">
<titleref>&wsa-core.title;</titleref>, M. Gudgin, M. Hadley, Editors.</bibl>
- <!--
- <bibl key="WS-Addressing-WSDL" id="WSADDR-WSDL"
- href="&w3c-designation-wsa-wsdl;">
- <titleref>&wsa-wsdl.title;</titleref>, M. Gudgin, M. Hadley, Editors.</bibl>
- *** For LC drafts ONLY ***
- -->
<bibl key="WS-Addressing-WSDL" id="WSADDR-WSDL"
href="http://www.w3.org/TR/2005/WD-ws-addr-wsdl-20050215">
--- 929,932 ----
Received on Wednesday, 20 July 2005 18:21:45 UTC