W3C home > Mailing lists > Public > public-ws-resource-access-notifications@w3.org > May 2010

WWW/2002/ws/ra/edcopies wsmex.html,1.123,1.124 wsmex.xml,1.110,1.111

From: Doug Davis via cvs-syncmail <cvsmail@w3.org>
Date: Tue, 11 May 2010 17:37:33 +0000
To: public-ws-resource-access-notifications@w3.org
Message-Id: <E1OBtOf-0007m7-88@lionel-hutz.w3.org>
Update of /w3ccvs/WWW/2002/ws/ra/edcopies
In directory hutz:/tmp/cvs-serv29799

Modified Files:
	wsmex.html wsmex.xml 
Log Message:
9570


Index: wsmex.xml
===================================================================
RCS file: /w3ccvs/WWW/2002/ws/ra/edcopies/wsmex.xml,v
retrieving revision 1.110
retrieving revision 1.111
diff -u -d -r1.110 -r1.111
--- wsmex.xml	11 May 2010 03:46:56 -0000	1.110
+++ wsmex.xml	11 May 2010 17:37:31 -0000	1.111
@@ -2196,116 +2196,47 @@
    <head>Security Considerations</head>
 
    <p>
-    It is strongly RECOMMENDED that the communication between Web services 
-    be secured using the mechanisms described in WS-Security 
-    <bibref ref='WSSecurity'/>. In order to properly secure messages, 
-    the body and all relevant headers need to be included in the 
-    signature. Specifically, any standard messaging headers, such as 
-    those from WS-Addressing 
-    <bibref ref='AddrCore'/>, need to be signed with the body in 
-    order to "bind" the two together.
-   </p>
-   
-   <p>
-    Different security mechanisms might be desired depending on the 
-    frequency of messages. For example, for infrequent messages, public key 
-    technologies might be adequate for integrity and confidentiality. 
-    However, for high-frequency events, it might be more performant to 
-    establish a security context for the events using the mechanisms 
-    described in <bibref ref='WSTrust'/> and 
-    <bibref ref='WSSecureConversation'/>. Note that if 
-    a shared secret is used it is RECOMMENDED that derived keys be used 
-    to strengthen the secret as described in WS-SecureConversation.
+    This specification considers two sets of security requirements, those of 
+    the applications that use the WS-MetadataExchange protocol and those of 
+    the protocol itself.
    </p>
-   
-   <p>
-    Requests for metadata that are not available to anonymous parties are 
-    strongly RECOMMENDED to require usage of WS-Security so that the 
-    requester can be authenticated and authorized to access the indicated 
-    metadata. Similarly, integrity and confidentiality SHOULD be used 
-    whenever metadata has restricted access.
-   </p> 
 
    <p>
-    Recipients of metadata are RECOMMENDED to validate the signature 
-    to authenticate and verify the integrity of the data. Specifically, 
-    recipients SHOULD verify that the sender has the right to "speak" for 
-    the metadata. This is important because some metadata, such as 
-    schemas, have embedded target IRIs that might be outside the scope 
-    of the sender. 
-   </p>
-   
-   <p>
-    Additionally, some metadata formats, such as policies 
-    <bibref ref='wspolicy'/>, can have embedded security 
-    semantics. These SHOULD be verified using the same considerations 
-    outlined in this section.
+    This specification makes no assumptions about the security requirements 
+    of the applications that use WS-MetadataExchange. However, once those 
+    requirements have been satisfied within a given operational context, 
+    the addition of WS-MetadataExchange to this operational context can 
+    not undermine the fulfillment of those requirements; the use of 
+    WS-MetadataExchange SHOULD NOT create additional attack vectors within 
+    an otherwise secure system.
    </p>
- 
+
    <p>
-    The following list summarizes common classes of attacks that apply to 
-    this protocol and identifies the mechanism to prevent/mitigate 
-    the attacks:
+    The material below is not a "check list". There are many other security 
+    concerns that need to be considered when implementing or using this 
+    protocol. Implementers and users of this protocol are urged to perform a 
+    security analysis to determine their particular threat profile and the 
+    appropriate responses to those threats.
    </p>
 
-   <ulist>
-    <item>
-     <p>
-      <kw>Message alteration</kw> - Alteration is prevented by including 
-      signatures of the message information using WS-Security.
-     </p>
-    </item>
-    <item>
-     <p>
-      <kw>Message disclosure</kw> - Confidentiality is preserved by 
-      encrypting sensitive data using WS-Security.
-     </p>
-    </item>
-    <item>
-     <p>
-      <kw>Key integrity</kw> - Key integrity is maintained by using 
-      the strongest algorithms possible (by comparing secured policies 
-      - see <bibref ref='wspolicy'/> and 
-      <bibref ref='WSSecurityPolicy'/>)
-     </p>
-    </item>
-    <item>
-     <p>
-      <kw>Authentication</kw> - Authentication is established using the 
-      mechanisms described in WS-Security and WS-Trust. Each message is 
-      authenticated using the mechanisms described in WS-Security
-     </p>
-    </item>
-    <item>
-     <p>
-      <kw>Accountability</kw> - Accountability is a function of the type 
-      of and strength of the key and algorithms being used. In many 
-      cases, a strong symmetric key provides sufficient accountability. 
-      However, in some environments, strong PKI signatures are needed.
-     </p>
-    </item>
-    <item>
-     <p>
-      <kw>Availability</kw> - Metadata services are subject to a variety 
-      of availability attacks such as application-level denial of 
-      service. It is RECOMMENDED that the mechanisms described in 
-      WS-Security be considered as mitigations for some forms of 
-      attacks. Other attacks, such as network-level denial of service 
-      are harder to avoid. Note that both of these classes of attack 
-      are outside the scope of this specification.
-     </p>
-    </item>
-    <item>
-     <p>
-      <kw>Replay</kw> - Messages can be replayed for a variety of 
-      reasons. To detect and eliminate this attack, mechanisms SHOULD 
-      be used to identify replayed messages such as the timestamp/nonce 
-      outlined in WS-Security. Alternatively, and OPTIONALLY, other 
-      technologies, such as sequencing, can also be used to prevent 
-      replay of application messages.
-     </p>
-    </item>
-   </ulist>
+   <div2>
+    <head>Metadata and Security Bootstrapping</head>
+
+    <p>
+     There are cases in which the metadata used to describe a service might 
+     be considered sensitive information. In these cases it is advisable 
+     for services to authenticate and authorize consumers as part of the 
+     processing of any requests for this metadata. However, because the 
+     security aspects of a service (e.g. supported protocols and token 
+     formats, cipher suites, etc.) are usually described using metadata 
+     (i.e. the constructs defined by WS-SecurityPolicy), there is an obvious 
+     dilemma when attempting to protect metadata in this way. Services 
+     wishing to protect access to their metadata are advised to use the 
+     mechanisms described in <specref ref="bootstrapping"/> to advertise 
+     the security requirements for clients wishing to access metadata via 
+     the mechanisms defined in this specification.
+    </p>
+   </div2>
   </div1>
 
   <div1 id="metadata">
@@ -3511,6 +3442,13 @@
        <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=9087">9087</loc>
       </td>
      </tr>
+     <tr>
+      <td> 2010/05/11 </td>
+      <td> DD </td>
+      <td> Added resolution of issue 
+       <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=9570">9570</loc>
+      </td>
+     </tr>
     </tbody>
    </table>
   </div1>

Index: wsmex.html
===================================================================
RCS file: /w3ccvs/WWW/2002/ws/ra/edcopies/wsmex.html,v
retrieving revision 1.123
retrieving revision 1.124
diff -u -d -r1.123 -r1.124
--- wsmex.html	11 May 2010 03:46:56 -0000	1.123
+++ wsmex.html	11 May 2010 17:37:31 -0000	1.124
@@ -67,13 +67,14 @@
 &nbsp;&nbsp;&nbsp;8.2 <a href="#WSPAEPR">Associating Policies with Endpoint References</a><br/>
 9 <a href="#ImplicitWSDL">Exposing Metadata for Implicitly Defined Features</a><br/>
 10 <a href="#Security">Security Considerations</a><br/>
+&nbsp;&nbsp;&nbsp;10.1 <a href="#iddiv2_1_1565">Metadata and Security Bootstrapping</a><br/>
 11 <a href="#metadata">WS-MetadataExchange Metadata</a><br/>
-&nbsp;&nbsp;&nbsp;11.1 <a href="#iddiv2_1_1641">MetadataExchange Assertion</a><br/>
+&nbsp;&nbsp;&nbsp;11.1 <a href="#iddiv2_1_1586">MetadataExchange Assertion</a><br/>
 12 <a href="#bootstrapping">Boostrapping Metadata Retrieval</a><br/>
 13 <a href="#acks">Acknowledgements</a><br/>
 14 <a href="#References">References</a><br/>
-&nbsp;&nbsp;&nbsp;14.1 <a href="#iddiv2_1_1797">Normative References</a><br/>
-&nbsp;&nbsp;&nbsp;14.2 <a href="#iddiv2_1_1983">Informative References</a><br/>
+&nbsp;&nbsp;&nbsp;14.1 <a href="#iddiv2_1_1742">Normative References</a><br/>
+&nbsp;&nbsp;&nbsp;14.2 <a href="#iddiv2_1_1928">Informative References</a><br/>
 </p>
 <h3><a name="appendices" id="appendices"/>Appendices</h3><p class="toc">A <a href="#Appendix-A">XML Schema</a><br/>
 B <a href="#Appendix-B">WSDL</a><br/>
@@ -1341,75 +1342,38 @@
 (10)   &lt;/wsa:Metadata&gt;
 (11) &lt;/wse:Notify&gt; </pre></div></div></div><div class="div1">
 <h2><a name="Security" id="Security"/>10 Security Considerations</h2><p>
-    It is strongly RECOMMENDED that the communication between Web services 
-    be secured using the mechanisms described in WS-Security 
-    <a href="#WSSecurity">[WS-Security]</a>. In order to properly secure messages, 
-    the body and all relevant headers need to be included in the 
-    signature. Specifically, any standard messaging headers, such as 
-    those from WS-Addressing 
-    <a href="#AddrCore">[WS-Addressing]</a>, need to be signed with the body in 
-    order to "bind" the two together.
-   </p><p>
-    Different security mechanisms might be desired depending on the 
-    frequency of messages. For example, for infrequent messages, public key 
-    technologies might be adequate for integrity and confidentiality. 
-    However, for high-frequency events, it might be more performant to 
-    establish a security context for the events using the mechanisms 
-    described in <a href="#WSTrust">[WS-Trust]</a> and 
-    <a href="#WSSecureConversation">[WS-SecureConversation]</a>. Note that if 
-    a shared secret is used it is RECOMMENDED that derived keys be used 
-    to strengthen the secret as described in WS-SecureConversation.
-   </p><p>
-    Requests for metadata that are not available to anonymous parties are 
-    strongly RECOMMENDED to require usage of WS-Security so that the 
-    requester can be authenticated and authorized to access the indicated 
-    metadata. Similarly, integrity and confidentiality SHOULD be used 
-    whenever metadata has restricted access.
-   </p><p>
-    Recipients of metadata are RECOMMENDED to validate the signature 
-    to authenticate and verify the integrity of the data. Specifically, 
-    recipients SHOULD verify that the sender has the right to "speak" for 
-    the metadata. This is important because some metadata, such as 
-    schemas, have embedded target IRIs that might be outside the scope 
-    of the sender. 
+    This specification considers two sets of security requirements, those of 
+    the applications that use the WS-MetadataExchange protocol and those of 
+    the protocol itself.
    </p><p>
-    Additionally, some metadata formats, such as policies 
-    <a href="#wspolicy">[WS-Policy]</a>, can have embedded security 
-    semantics. These SHOULD be verified using the same considerations 
-    outlined in this section.
+    This specification makes no assumptions about the security requirements 
+    of the applications that use WS-MetadataExchange. However, once those 
+    requirements have been satisfied within a given operational context, 
+    the addition of WS-MetadataExchange to this operational context can 
+    not undermine the fulfillment of those requirements; the use of 
+    WS-MetadataExchange SHOULD NOT create additional attack vectors within 
+    an otherwise secure system.
    </p><p>
-    The following list summarizes common classes of attacks that apply to 
-    this protocol and identifies the mechanism to prevent/mitigate 
-    the attacks:
-   </p><ul><li><p><b>Message alteration</b> - Alteration is prevented by including 
-      signatures of the message information using WS-Security.
-     </p></li><li><p><b>Message disclosure</b> - Confidentiality is preserved by 
-      encrypting sensitive data using WS-Security.
-     </p></li><li><p><b>Key integrity</b> - Key integrity is maintained by using 
-      the strongest algorithms possible (by comparing secured policies 
-      - see <a href="#wspolicy">[WS-Policy]</a> and 
-      <a href="#WSSecurityPolicy">[WS-SecurityPolicy]</a>)
-     </p></li><li><p><b>Authentication</b> - Authentication is established using the 
-      mechanisms described in WS-Security and WS-Trust. Each message is 
-      authenticated using the mechanisms described in WS-Security
-     </p></li><li><p><b>Accountability</b> - Accountability is a function of the type 
-      of and strength of the key and algorithms being used. In many 
-      cases, a strong symmetric key provides sufficient accountability. 
-      However, in some environments, strong PKI signatures are needed.
-     </p></li><li><p><b>Availability</b> - Metadata services are subject to a variety 
-      of availability attacks such as application-level denial of 
-      service. It is RECOMMENDED that the mechanisms described in 
-      WS-Security be considered as mitigations for some forms of 
-      attacks. Other attacks, such as network-level denial of service 
-      are harder to avoid. Note that both of these classes of attack 
-      are outside the scope of this specification.
-     </p></li><li><p><b>Replay</b> - Messages can be replayed for a variety of 
-      reasons. To detect and eliminate this attack, mechanisms SHOULD 
-      be used to identify replayed messages such as the timestamp/nonce 
-      outlined in WS-Security. Alternatively, and OPTIONALLY, other 
-      technologies, such as sequencing, can also be used to prevent 
-      replay of application messages.
-     </p></li></ul></div><div class="div1">
+    The material below is not a "check list". There are many other security 
+    concerns that need to be considered when implementing or using this 
+    protocol. Implementers and users of this protocol are urged to perform a 
+    security analysis to determine their particular threat profile and the 
+    appropriate responses to those threats.
+   </p><div class="div2">
+<h3><a name="iddiv2_1_1565" id="iddiv2_1_1565"/>10.1 Metadata and Security Bootstrapping</h3><p>
+     There are cases in which the metadata used to describe a service might 
+     be considered sensitive information. In these cases it is advisable 
+     for services to authenticate and authorize consumers as part of the 
+     processing of any requests for this metadata. However, because the 
+     security aspects of a service (e.g. supported protocols and token 
+     formats, cipher suites, etc.) are usually described using metadata 
+     (i.e. the constructs defined by WS-SecurityPolicy), there is an obvious 
+     dilemma when attempting to protect metadata in this way. Services 
+     wishing to protect access to their metadata are advised to use the 
+     mechanisms described in <a href="#bootstrapping"><b>12 Boostrapping Metadata Retrieval</b></a> to advertise 
+     the security requirements for clients wishing to access metadata via 
+     the mechanisms defined in this specification.
+    </p></div></div><div class="div1">
 <h2><a name="metadata" id="metadata"/>11 WS-MetadataExchange Metadata</h2><p>
     An endpoint MAY indicate its support of WS-MetadataExchange, or its 
     features,
@@ -1434,7 +1398,7 @@
     indicate a particular security mechanism used to protect the
     WS-MetadataExchange operations supported by this endpoint.
    </p><div class="div2">
-<h3><a name="iddiv2_1_1641" id="iddiv2_1_1641"/>11.1 MetadataExchange Assertion</h3><p>
+<h3><a name="iddiv2_1_1586" id="iddiv2_1_1586"/>11.1 MetadataExchange Assertion</h3><p>
      Services indicate support for the WS-MetadataExchange specification 
      through the use of the Web Services
      Policy - Framework <a href="#wspolicy">[WS-Policy]</a> and Web Services Policy -
@@ -1590,7 +1554,7 @@
      Yves Lafon (W3C/ERCIM).
    </p></div><div class="div1">
 <h2><a name="References" id="References"/>14 References</h2><div class="div2">
-<h3><a name="iddiv2_1_1797" id="iddiv2_1_1797"/>14.1 Normative References</h3><dl><dt class="label"><a name="RFC2119" id="RFC2119"/>RFC 2119</dt><dd><a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>
+<h3><a name="iddiv2_1_1742" id="iddiv2_1_1742"/>14.1 Normative References</h3><dl><dt class="label"><a name="RFC2119" id="RFC2119"/>RFC 2119</dt><dd><a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>
         Key words for use in RFCs to Indicate Requirement Levels
        </cite></a>
        , S. Bradner, Author.
@@ -1662,7 +1626,7 @@
        , P. Biron, A. Malhotra, Editors.
        World Wide Web Consortium (W3C), 28 October 2004.
       Available at <a href="http://www.w3.org/TR/xmlschema-2/">http://www.w3.org/TR/xmlschema-2/</a>.</dd></dl></div><div class="div2">
-<h3><a name="iddiv2_1_1983" id="iddiv2_1_1983"/>14.2 Informative References</h3><dl><dt class="label"><a name="WSSecureConversation" id="WSSecureConversation"/>WS-SecureConversation</dt><dd><a href="http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.4/os/ws-secureconversation-1.4-spec-os.doc"><cite>
+<h3><a name="iddiv2_1_1928" id="iddiv2_1_1928"/>14.2 Informative References</h3><dl><dt class="label"><a name="WSSecureConversation" id="WSSecureConversation"/>WS-SecureConversation</dt><dd><a href="http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.4/os/ws-secureconversation-1.4-spec-os.doc"><cite>
         OASIS Standard, "Web Services Secure Conversation
           (WS-SecureConversation) 1.4"
        </cite></a>
@@ -1992,4 +1956,5 @@
        <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=9031">9031</a></td></tr><tr><td> 2010/03/30 </td><td> DD </td><td> Added resolution of issue 
        <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=9266">9266</a></td></tr><tr><td> 2010/04/20 </td><td> DD </td><td> Added resolution of issue 
        <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=9250">9250</a></td></tr><tr><td> 2010/05/04 </td><td> DD </td><td> Added resolution of issue 
-       <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=9087">9087</a></td></tr></tbody></table></div></div></body></html>
\ No newline at end of file
+       <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=9087">9087</a></td></tr><tr><td> 2010/05/11 </td><td> DD </td><td> Added resolution of issue 
+       <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=9570">9570</a></td></tr></tbody></table></div></div></body></html>
\ No newline at end of file
Received on Tuesday, 11 May 2010 17:37:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 May 2010 17:37:36 GMT