- 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
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><wsa:ReferenceParameters></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 @@
6.3 <a href="#PutDenied">PutDenied</a><br/>
6.4 <a href="#UnknownResource">UnknownResource</a><br/>
7 <a href="#Security_Considerations">Security Considerations</a><br/>
+ 7.1 <a href="#iddiv2_1_1311">Protecting Resources</a><br/>
+ 7.2 <a href="#iddiv2_1_1316">Protecting Resource Factories</a><br/>
8 <a href="#metadata">WS-Transfer Metadata</a><br/>
- 8.1 <a href="#iddiv2_1_1391">TransferResource Assertion</a><br/>
- 8.2 <a href="#iddiv2_1_1473">TransferResourceFactory Assertion</a><br/>
+ 8.1 <a href="#iddiv2_1_1334">TransferResource Assertion</a><br/>
+ 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/>
- 10.1 <a href="#iddiv2_1_1538">Normative References</a><br/>
- 10.2 <a href="#iddiv2_1_1711">Informative References</a><br/>
+ 10.1 <a href="#iddiv2_1_1481">Normative References</a><br/>
+ 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><wsa:ReferenceParameters></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 UTC