- 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
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 @@
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/>
+ 10.1 <a href="#iddiv2_1_1565">Metadata and Security Bootstrapping</a><br/>
11 <a href="#metadata">WS-MetadataExchange Metadata</a><br/>
- 11.1 <a href="#iddiv2_1_1641">MetadataExchange Assertion</a><br/>
+ 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/>
- 14.1 <a href="#iddiv2_1_1797">Normative References</a><br/>
- 14.2 <a href="#iddiv2_1_1983">Informative References</a><br/>
+ 14.1 <a href="#iddiv2_1_1742">Normative References</a><br/>
+ 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) </wsa:Metadata>
(11) </wse:Notify> </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 UTC