W3C home > Mailing lists > Public > public-ws-addressing-eds@w3.org > July to September 2005

2004/ws/addressing ws-addr-soap.xml,1.84,1.85 ws-addr-core.xml,1.105,1.106

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
Message-Id: <E1DvJCK-0006T7-P4@lionel-hutz.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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:19:40 GMT