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

WWW/2002/ws/ra/edcopies wst.html,1.121,1.122 wst.xml,1.118,1.119

From: Doug Davis via cvs-syncmail <cvsmail@w3.org>
Date: Tue, 11 May 2010 19:23:50 +0000
To: public-ws-resource-access-notifications@w3.org
Message-Id: <E1OBv3X-0004mV-0V@lionel-hutz.w3.org>
Update of /w3ccvs/WWW/2002/ws/ra/edcopies
In directory hutz:/tmp/cvs-serv18289

Modified Files:
	wst.html wst.xml 
Log Message:
9569


Index: wst.xml
===================================================================
RCS file: /w3ccvs/WWW/2002/ws/ra/edcopies/wst.xml,v
retrieving revision 1.118
retrieving revision 1.119
diff -u -d -r1.118 -r1.119
--- wst.xml	5 May 2010 02:42:44 -0000	1.118
+++ wst.xml	11 May 2010 19:23:48 -0000	1.119
@@ -1655,120 +1655,55 @@
   <div1 id="Security_Considerations">
    <head>Security Considerations</head>
    <p>
-    It is strongly RECOMMENDED that the communication between services be
-    secured using the mechanisms described in <bibref ref="WSSecurity"/>.
+    This specification considers two sets of security requirements, those 
+    of the applications that use the WS-Transfer protocol and those of 
+    the protocol itself.
    </p>
 
    <p>
-    In order to properly secure messages, the body (even if empty) and all
-    relevant headers need to be included in the signature. Specifically, the
-    WS-Addressing header blocks, WS-Security timestamp, and any header blocks
-    resulting from a <code>&lt;wsa:ReferenceParameters&gt;</code> in references
-    need to be signed along with the body in order to "bind" them together and
-    prevent certain types of attacks.
+    This specification makes no assumptions about the security requirements 
+    of the applications that use WS-Transfer. However, once those 
+    requirements have been satisfied within a given operational context, 
+    the addition of WS-Transfer to this operational context can not 
+    undermine the fulfillment of those requirements; the use of 
+    WS-Transfer SHOULD NOT create additional attack vectors within 
+    an otherwise secure system.
    </p>
-
+   
    <p>
-    If a requestor is issuing multiple messages to a resource reference, then
-    it is RECOMMENDED that a security context be established using the mechanisms
-    described in WS-Trust and WS-SecureConversation. It is further RECOMMENDED
-    that if shared secrets are used, message-specific derived keys also be used
-    to protect the secret from crypto attacks.</p>
-      <p>The access control semantics of resource references is out-of-scope of
-    this specification and are specific to each resource reference. Similarly,
-    any protection mechanisms on resource references independent of transfer
-    (e.g. embedded signatures and encryption) are also out-of-scope.
+    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>
 
-   <p>
-    It is RECOMMENDED that the security considerations of WS-Security also be
-    considered.
-   </p>
+   <div2>
+    <head>Protecting Resources</head>
+    <p>
+     Both resources and the information that makes up their representation 
+     might be sensitive. In these cases, it is advisable for resource 
+     managers to authenticate and authorize clients attempting Get, Put, 
+     or Delete operations. To protect representations sent over a network, 
+     the wst:Get, wst:GetResponse, wst:Put, and wst:PutResponse messages 
+     ought to have the appropriate authenticity, integrity, and 
+     confidentiality measures applied.
+    </p>
+   </div2>
 
-   <p>
-    While a comprehensive listing of attacks is not feasible, the following
-    list summarizes common classes of attacks that apply to this protocol and
-    identifies the mechanism(s) to prevent/mitigate the attacks.
-   </p>
+   <div2>
+    <head>Protecting Resource Factories</head>
+    <p>
+     In cases where resources and/or the information that makes up their 
+     representation are sensitive so, too, are the services that create 
+     these resources. In such cases it is advisable for resource factories 
+     to authenticate and authorize clients attempting Create operations. 
+     To protect representations sent over a network, wst:CreateResponse 
+     messages that include representations ought to have the appropriate 
+     authenticity, integrity, and confidentiality measures applied. 
+    </p>
+   </div2>
 
-   <ulist>
-    <item>
-     <p>
-      <emph>Replay</emph> -  Messages, or portions of messages, can be
-      replayed in an attempt to gain access or disrupt services. Freshness
-      checks such as timestamps, digests, and sequences can be used to detect
-      duplicate messages.
-     </p>
-    </item>
-    <item>
-     <p>
-      <emph>Invalid tokens</emph> - There are a number of token attacks
-      including certificate authorities, false signatures, and PKI attacks.
-      Care SHOULD be taken to ensure each token is valid (usage window, digest,
-      signing authority, revocation, ...), and that the appropriate delegation
-      policies are in compliance.
-     </p>
-    </item>
-    <item>
-     <p>
-      <emph>Man-in-the-middle</emph> - The message exchanges in this
-      specification could be subject to man-in-the-middle attacks so care
-      SHOULD be taken to reduce possibilities here such as establishing a
-      secure channel and verifying that the security tokens user represent
-      identities authorized to speak for, or on behalf of, the desired resource
-      reference.
-     </p>
-    </item>
-    <item>
-     <p>
-      <emph>Message alteration</emph> - Alteration is prevented by
-      including signatures of the message information using WS-Security. Care
-      SHOULD be taken to review message part references to ensure they haven't
-      been forged (e.g. ID duplication).
-     </p>
-    </item>
-    <item>
-     <p>
-      <emph>Message disclosure</emph> - Confidentiality is preserved by
-      encrypting sensitive data using WS-Security.
-     </p>
-    </item>
-    <item>
-     <p>
-      <emph>Key integrity</emph> - Key integrity is maintained by using
-      the strongest algorithms possible (by comparing secured policies - see
-      <bibref ref="wspolicy"/>
-      and <bibref ref="WSSecurityPolicy"/>
-      and by using derived keys (<bibref ref="WSSecureConversation"/>).
-     </p>
-    </item>
-    <item>
-     <p>
-      <emph>Authentication</emph> - 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>
-      <emph>Accountability</emph> - Accountability is a function of the
-      type of and string 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>
-      <emph>Availability</emph> - All reliable messaging services are
-      subject to a variety of availability attacks. Replay detection is a
-      common attack and it is RECOMMENDED that this be addressed by the
-      mechanisms described in WS-Security. Other attacks, such as network-level
-      denial of service attacks are harder to avoid and are outside the scope
-      of this specification. That said, care SHOULD be taken to ensure that
-      minimal state is saved prior to any authenticating sequences.
-     </p>
-    </item>
-   </ulist>
   </div1>
 
   <div1 id="metadata">
@@ -2994,6 +2929,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=9569">9569</loc>
+      </td>
+     </tr>
     </tbody>
    </table>
   </div1>

Index: wst.html
===================================================================
RCS file: /w3ccvs/WWW/2002/ws/ra/edcopies/wst.html,v
retrieving revision 1.121
retrieving revision 1.122
diff -u -d -r1.121 -r1.122
--- wst.html	5 May 2010 02:42:44 -0000	1.121
+++ wst.html	11 May 2010 19:23:48 -0000	1.122
@@ -59,13 +59,15 @@
 &nbsp;&nbsp;&nbsp;6.3 <a href="#PutDenied">PutDenied</a><br/>
 &nbsp;&nbsp;&nbsp;6.4 <a href="#UnknownResource">UnknownResource</a><br/>
 7 <a href="#Security_Considerations">Security Considerations</a><br/>
+&nbsp;&nbsp;&nbsp;7.1 <a href="#iddiv2_1_1311">Protecting Resources</a><br/>
+&nbsp;&nbsp;&nbsp;7.2 <a href="#iddiv2_1_1316">Protecting Resource Factories</a><br/>
 8 <a href="#metadata">WS-Transfer Metadata</a><br/>
-&nbsp;&nbsp;&nbsp;8.1 <a href="#iddiv2_1_1391">TransferResource Assertion</a><br/>
-&nbsp;&nbsp;&nbsp;8.2 <a href="#iddiv2_1_1473">TransferResourceFactory Assertion</a><br/>
+&nbsp;&nbsp;&nbsp;8.1 <a href="#iddiv2_1_1334">TransferResource Assertion</a><br/>
+&nbsp;&nbsp;&nbsp;8.2 <a href="#iddiv2_1_1416">TransferResourceFactory Assertion</a><br/>
 9 <a href="#acks">Acknowledgements</a><br/>
 10 <a href="#refs">References</a><br/>
-&nbsp;&nbsp;&nbsp;10.1 <a href="#iddiv2_1_1538">Normative References</a><br/>
-&nbsp;&nbsp;&nbsp;10.2 <a href="#iddiv2_1_1711">Informative References</a><br/>
+&nbsp;&nbsp;&nbsp;10.1 <a href="#iddiv2_1_1481">Normative References</a><br/>
+&nbsp;&nbsp;&nbsp;10.2 <a href="#iddiv2_1_1654">Informative References</a><br/>
 </p>
 <h3><a name="appendices" id="appendices"/>Appendices</h3><p class="toc">A <a href="#Appendix_I__E2_80_93_XSD">XML Schema</a><br/>
 B <a href="#WSDL">WSDL</a><br/>
@@ -948,72 +950,42 @@
         The resource is not known.
        </td></tr><tr><th align="left"><b>[Detail]</b></th><td><em>none</em></td></tr></tbody></table></div></div><div class="div1">
 <h2><a name="Security_Considerations" id="Security_Considerations"/>7 Security Considerations</h2><p>
-    It is strongly RECOMMENDED that the communication between services be
-    secured using the mechanisms described in <a href="#WSSecurity">[WS-Security]</a>.
-   </p><p>
-    In order to properly secure messages, the body (even if empty) and all
-    relevant headers need to be included in the signature. Specifically, the
-    WS-Addressing header blocks, WS-Security timestamp, and any header blocks
-    resulting from a <code>&lt;wsa:ReferenceParameters&gt;</code> in references
-    need to be signed along with the body in order to "bind" them together and
-    prevent certain types of attacks.
-   </p><p>
-    If a requestor is issuing multiple messages to a resource reference, then
-    it is RECOMMENDED that a security context be established using the mechanisms
-    described in WS-Trust and WS-SecureConversation. It is further RECOMMENDED
-    that if shared secrets are used, message-specific derived keys also be used
-    to protect the secret from crypto attacks.</p><p>The access control semantics of resource references is out-of-scope of
-    this specification and are specific to each resource reference. Similarly,
-    any protection mechanisms on resource references independent of transfer
-    (e.g. embedded signatures and encryption) are also out-of-scope.
+    This specification considers two sets of security requirements, those 
+    of the applications that use the WS-Transfer protocol and those of 
+    the protocol itself.
    </p><p>
-    It is RECOMMENDED that the security considerations of WS-Security also be
-    considered.
+    This specification makes no assumptions about the security requirements 
+    of the applications that use WS-Transfer. However, once those 
+    requirements have been satisfied within a given operational context, 
+    the addition of WS-Transfer to this operational context can not 
+    undermine the fulfillment of those requirements; the use of 
+    WS-Transfer SHOULD NOT create additional attack vectors within 
+    an otherwise secure system.
    </p><p>
-    While a comprehensive listing of attacks is not feasible, the following
-    list summarizes common classes of attacks that apply to this protocol and
-    identifies the mechanism(s) to prevent/mitigate the attacks.
-   </p><ul><li><p><em>Replay</em> -  Messages, or portions of messages, can be
-      replayed in an attempt to gain access or disrupt services. Freshness
-      checks such as timestamps, digests, and sequences can be used to detect
-      duplicate messages.
-     </p></li><li><p><em>Invalid tokens</em> - There are a number of token attacks
-      including certificate authorities, false signatures, and PKI attacks.
-      Care SHOULD be taken to ensure each token is valid (usage window, digest,
-      signing authority, revocation, ...), and that the appropriate delegation
-      policies are in compliance.
-     </p></li><li><p><em>Man-in-the-middle</em> - The message exchanges in this
-      specification could be subject to man-in-the-middle attacks so care
-      SHOULD be taken to reduce possibilities here such as establishing a
-      secure channel and verifying that the security tokens user represent
-      identities authorized to speak for, or on behalf of, the desired resource
-      reference.
-     </p></li><li><p><em>Message alteration</em> - Alteration is prevented by
-      including signatures of the message information using WS-Security. Care
-      SHOULD be taken to review message part references to ensure they haven't
-      been forged (e.g. ID duplication).
-     </p></li><li><p><em>Message disclosure</em> - Confidentiality is preserved by
-      encrypting sensitive data using WS-Security.
-     </p></li><li><p><em>Key integrity</em> - 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>
-      and by using derived keys (<a href="#WSSecureConversation">[WS-SecureConversation]</a>).
-     </p></li><li><p><em>Authentication</em> - 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><em>Accountability</em> - Accountability is a function of the
-      type of and string 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><em>Availability</em> - All reliable messaging services are
-      subject to a variety of availability attacks. Replay detection is a
-      common attack and it is RECOMMENDED that this be addressed by the
-      mechanisms described in WS-Security. Other attacks, such as network-level
-      denial of service attacks are harder to avoid and are outside the scope
-      of this specification. That said, care SHOULD be taken to ensure that
-      minimal state is saved prior to any authenticating sequences.
-     </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_1311" id="iddiv2_1_1311"/>7.1 Protecting Resources</h3><p>
+     Both resources and the information that makes up their representation 
+     might be sensitive. In these cases, it is advisable for resource 
+     managers to authenticate and authorize clients attempting Get, Put, 
+     or Delete operations. To protect representations sent over a network, 
+     the wst:Get, wst:GetResponse, wst:Put, and wst:PutResponse messages 
+     ought to have the appropriate authenticity, integrity, and 
+     confidentiality measures applied.
+    </p></div><div class="div2">
+<h3><a name="iddiv2_1_1316" id="iddiv2_1_1316"/>7.2 Protecting Resource Factories</h3><p>
+     In cases where resources and/or the information that makes up their 
+     representation are sensitive so, too, are the services that create 
+     these resources. In such cases it is advisable for resource factories 
+     to authenticate and authorize clients attempting Create operations. 
+     To protect representations sent over a network, wst:CreateResponse 
+     messages that include representations ought to have the appropriate 
+     authenticity, integrity, and confidentiality measures applied. 
+    </p></div></div><div class="div1">
 <h2><a name="metadata" id="metadata"/>8 WS-Transfer Metadata</h2><p>
     An endpoint MAY indicate its support of WS-Transfer, or its features,
     by including the WS-Transfer TransferResource or TransferResourceFactory
@@ -1038,7 +1010,7 @@
     that indicate a particular security mechanism used to protect
     the WS-Transfer operations supported by this endpoint.
    </p><div class="div2">
-<h3><a name="iddiv2_1_1391" id="iddiv2_1_1391"/>8.1 TransferResource Assertion</h3><p>
+<h3><a name="iddiv2_1_1334" id="iddiv2_1_1334"/>8.1 TransferResource Assertion</h3><p>
      Services indicate support for the
      WS-Transfer's definition of a Transfer Resource
      through the use of the Web Services
@@ -1103,7 +1075,7 @@
      Note: The WS-RA WG is interested in Last Call feedback on the use
      of nested policy expressions.
     </p></div><div class="div2">
-<h3><a name="iddiv2_1_1473" id="iddiv2_1_1473"/>8.2 TransferResourceFactory Assertion</h3><p>
+<h3><a name="iddiv2_1_1416" id="iddiv2_1_1416"/>8.2 TransferResourceFactory Assertion</h3><p>
      Services indicate support for
      WS-Transfer's definition of a Transfer Resource Factory
      through the use of the Web Services
@@ -1175,7 +1147,7 @@
       Yves Lafon (W3C/ERCIM).
    </p></div><div class="div1">
 <h2><a name="refs" id="refs"/>10 References</h2><div class="div2">
-<h3><a name="iddiv2_1_1538" id="iddiv2_1_1538"/>10.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_1481" id="iddiv2_1_1481"/>10.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.
@@ -1243,7 +1215,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_1711" id="iddiv2_1_1711"/>10.2 Informative References</h3><dl><dt class="label"><a name="WsFrag" id="WsFrag"/>WS-Fragment</dt><dd><a href="http://www.w3.org/TR/ws-fragment"><cite>
+<h3><a name="iddiv2_1_1654" id="iddiv2_1_1654"/>10.2 Informative References</h3><dl><dt class="label"><a name="WsFrag" id="WsFrag"/>WS-Fragment</dt><dd><a href="http://www.w3.org/TR/ws-fragment"><cite>
        W3C Working Group Draft, "Web Services Fragment (WS-Fragment) 1.0"
       </cite></a>
       , D. Davis, et al., Editors.
@@ -1611,4 +1583,5 @@
        <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=8198">8198</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/05/04 </td><td> DD </td><td> Added resolution of issue 
        <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=9588">9588</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=9569">9569</a></td></tr></tbody></table></div></div></body></html>
\ No newline at end of file
Received on Tuesday, 11 May 2010 19:23:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 May 2010 19:23:53 GMT