- From: Toufic Boubez via cvs-syncmail <cvsmail@w3.org>
- Date: Mon, 25 Sep 2006 03:57:36 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv28225
Modified Files:
ws-policy-primer.xml ws-policy-framework.xml
ws-policy-framework.html
Log Message:
Implemented the editorial action http://www.w3.org/2005/06/tracker/wspolicyeds/actions/35
to move the Security Considerations section to the Framework document.
Index: ws-policy-framework.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-framework.xml,v
retrieving revision 1.50
retrieving revision 1.51
diff -u -d -r1.50 -r1.51
--- ws-policy-framework.xml 21 Sep 2006 18:28:04 -0000 1.50
+++ ws-policy-framework.xml 25 Sep 2006 03:57:33 -0000 1.51
@@ -1316,6 +1316,101 @@
could be secured as part of a SOAP message [<bibref ref="SOAP11"/>, <bibref ref="SOAP12"/>] using WS-Security [<bibref
ref="WS-Security"/>] or embedded within other
objects using object-specific security mechanisms.</p>
+
+ <p>This section describes the security considerations that service providers, requestors,
+ policy authors, policy assertion authors, and policy implementers need to consider when
+ exposing, consuming and designing policy expressions, authoring policy assertions or
+ implementing policy.</p>
+ <div2 id="information-disclosure-threats">
+ <head>Information Disclosure Threats</head>
+ <p>A policy is used to represent the capabilities and requirements of a Web Service.
+ Policies may include sensitive information. Malicious consumers may acquire sensitive
+ information, fingerprint the service and infer service vulnerabilities. These threats can
+ be mitigated by requiring authentication for sensitive information, by omitting sensitive
+ information from the policy or by securing access to the policy. For securing access to
+ policy metadata, policy providers can use mechanisms from other Web Services
+ specifications such as WS-Security and WS-MetadataExchange.</p>
+ </div2>
+ <div2 id="spoofing-and-tampering-threats">
+ <head>Spoofing and Tampering Threats</head>
+ <p>If a policy expression is unsigned it could be easily tampered with or replaced. To
+ prevent tampering or spoofing of policy, requestors should discard a policy unless it is
+ signed by the provider and presented with sufficient credentials. Requestors should also
+ check that the signer is actually authorized to express policies for the given policy
+ subject.</p>
+ </div2>
+ <div2 id="downgrade-threats">
+ <head>Downgrade Threats</head>
+ <p>A policy may offer several alternatives that vary from weak to strong set of
+ requirements. An adversary may interfere and remove all the alternatives except the
+ weakest one (say no security requirements). Or, an adversary may interfere and discard
+ this policy and insert a weaker policy previously issued by the same provider. Policy
+ authors or providers can mitigate these threats by sun-setting older or weaker policy
+ alternatives. Requestors can mitigate these threats by discarding policies unless they are
+ signed by the provider.</p>
+ </div2>
+ <div2 id="repudiation-threats">
+ <head>Repudiation Threats</head>
+ <p>Malicious providers may include policy assertions in its policy whose behavior cannot be
+ verified by examining the wire message from the provider to requestor. In general,
+ requestors have no guarantee that a provider will behave as described in the provider’s
+ policy expression. The provider may not and perform a malicious activity. For example, say
+ the policy assertion is privacy notice information and the provider violates the semantics
+ by disclosing private information. Requestors can mitigate this threat by discarding
+ policy alternatives which include assertions whose behavior cannot be verified by
+ examining the wire message from the provider to requestor. Assertion authors can mitigate
+ this threat by not designing assertions whose behavior cannot be verified using wire
+ messages.</p>
+ </div2>
+ <div2 id="denial-of-service-threats">
+ <head>Denial of Service Threats</head>
+ <p>Malicious providers may provide a policy expression with a large number of alternatives,
+ a large number of assertions in alternatives, deeply nested policy expressions or chains
+ of PolicyReference elements that expand exponentially (see the chained sample below; this
+ is similar to the well-known DTD entity expansion attack). Policy implementers need to
+ anticipate these rogue providers and use a configurable bound with defaults on number of
+ policy alternatives, number of assertions in an alternative, depth of nested policy
+ expressions, etc.</p>
+ <example>
+ <head>Chained Policy Reference Elements</head>
+ <eg xml:space="preserve"><Policy wsu:Id="p1">
+ <PolicyReference URI="#p2"/ >
+ <PolicyReference URI="#p2"/>
+ </Policy>
+
+ <Policy wsu:Id="p2" >
+ <PolicyReference URI="#p3"/>
+ <PolicyReference URI="#p3"/>
+ </Policy>
+
+ <Policy wsu:Id="p3" >
+ <PolicyReference URI="#p4"/>
+ <PolicyReference URI="#p4"/>
+ </Policy>
+
+ <!-- Policy/@wsu:Id p4 through p99 -->
+
+ <Policy wsu:Id="p100" >
+ <PolicyReference URI="#p101"/>
+ <PolicyReference URI="#p101"/>
+ </Policy>
+
+ <Policy wsu:Id="p101" >
+ <mtom:OptimizedMimeSerialization />
+ </Policy></eg>
+ </example>
+ <p>Malicious providers may provide a policy expression that includes multiple
+ PolicyReference elements that use a large number of different internet addresses. These
+ may require the consumers to establish a large number of TCP connections. Policy
+ implementers need to anticipate such rogue providers and use a configurable bound with
+ defaults on number of PolicyReference elements per policy expression.</p>
+ </div2>
+ <div2 id="general-xml-considerations">
+ <head>General XML Considerations</head>
+ <p>Implementers of Web Services policy language should be careful to protect their software
+ against general XML threats like deeply nested XML or XML that contains malicious
+ content.</p>
+ </div2>
</div1>
<div1 id='Conformance'>
<head>Conformance</head>
@@ -1835,6 +1930,14 @@
Semantics of successful intersection determined by domain-specific assertion content.
</td>
</tr>
+ <tr>
+ <td>20060924</td>
+ <td>TIB</td>
+ <td>Implemented the
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/35">editorial action 35</loc>
+ to include the Security Considerations section from the Primer document.
+ </td>
+ </tr>
</tbody>
</table>
</inform-div1>
Index: ws-policy-primer.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- ws-policy-primer.xml 19 Sep 2006 21:55:47 -0000 1.6
+++ ws-policy-primer.xml 25 Sep 2006 03:57:33 -0000 1.7
@@ -1818,103 +1818,6 @@
</div1>
</body>
<back>
- <div1 id="security-considerations">
- <head>Security Considerations</head>
- <p>This appendix describes the security considerations that service providers, requestors,
- policy authors, policy assertion authors, and policy implementers need to consider when
- exposing, consuming and designing policy expressions, authoring policy assertions or
- implementing policy.</p>
- <div2 id="information-disclosure-threats">
- <head>Information Disclosure Threats</head>
- <p>A policy is used to represent the capabilities and requirements of a Web Service.
- Policies may include sensitive information. Malicious consumers may acquire sensitive
- information, fingerprint the service and infer service vulnerabilities. These threats can
- be mitigated by requiring authentication for sensitive information, by omitting sensitive
- information from the policy or by securing access to the policy. For securing access to
- policy metadata, policy providers can use mechanisms from other Web Services
- specifications such as WS-Security and WS-MetadataExchange.</p>
- </div2>
- <div2 id="spoofing-and-tampering-threats">
- <head>Spoofing and Tampering Threats</head>
- <p>If a policy expression is unsigned it could be easily tampered with or replaced. To
- prevent tampering or spoofing of policy, requestors should discard a policy unless it is
- signed by the provider and presented with sufficient credentials. Requestors should also
- check that the signer is actually authorized to express policies for the given policy
- subject.</p>
- </div2>
- <div2 id="downgrade-threats">
- <head>Downgrade Threats</head>
- <p>A policy may offer several alternatives that vary from weak to strong set of
- requirements. An adversary may interfere and remove all the alternatives except the
- weakest one (say no security requirements). Or, an adversary may interfere and discard
- this policy and insert a weaker policy previously issued by the same provider. Policy
- authors or providers can mitigate these threats by sun-setting older or weaker policy
- alternatives. Requestors can mitigate these threats by discarding policies unless they are
- signed by the provider.</p>
- </div2>
- <div2 id="repudiation-threats">
- <head>Repudiation Threats</head>
- <p>Malicious providers may include policy assertions in its policy whose behavior cannot be
- verified by examining the wire message from the provider to requestor. In general,
- requestors have no guarantee that a provider will behave as described in the provider’s
- policy expression. The provider may not and perform a malicious activity. For example, say
- the policy assertion is privacy notice information and the provider violates the semantics
- by disclosing private information. Requestors can mitigate this threat by discarding
- policy alternatives which include assertions whose behavior cannot be verified by
- examining the wire message from the provider to requestor. Assertion authors can mitigate
- this threat by not designing assertions whose behavior cannot be verified using wire
- messages.</p>
- </div2>
- <div2 id="denial-of-service-threats">
- <head>Denial of Service Threats</head>
- <p>Malicious providers may provide a policy expression with a large number of alternatives,
- a large number of assertions in alternatives, deeply nested policy expressions or chains
- of PolicyReference elements that expand exponentially (see the chained sample below; this
- is similar to the well-known DTD entity expansion attack). Policy implementers need to
- anticipate these rogue providers and use a configurable bound with defaults on number of
- policy alternatives, number of assertions in an alternative, depth of nested policy
- expressions, etc.</p>
- <example>
- <head>Chained Policy Reference Elements</head>
- <eg xml:space="preserve"><Policy wsu:Id="p1">
- <PolicyReference URI="#p2"/ >
- <PolicyReference URI="#p2"/>
-</Policy>
-
-<Policy wsu:Id="p2" >
- <PolicyReference URI="#p3"/>
- <PolicyReference URI="#p3"/>
-</Policy>
-
-<Policy wsu:Id="p3" >
- <PolicyReference URI="#p4"/>
- <PolicyReference URI="#p4"/>
-</Policy>
-
-<!-- Policy/@wsu:Id p4 through p99 -->
-
-<Policy wsu:Id="p100" >
- <PolicyReference URI="#p101"/>
- <PolicyReference URI="#p101"/>
-</Policy>
-
-<Policy wsu:Id="p101" >
- <mtom:OptimizedMimeSerialization />
-</Policy></eg>
- </example>
- <p>Malicious providers may provide a policy expression that includes multiple
- PolicyReference elements that use a large number of different internet addresses. These
- may require the consumers to establish a large number of TCP connections. Policy
- implementers need to anticipate such rogue providers and use a configurable bound with
- defaults on number of PolicyReference elements per policy expression.</p>
- </div2>
- <div2 id="general-xml-considerations">
- <head>General XML Considerations</head>
- <p>Implementers of Web Services policy language should be careful to protect their software
- against general XML threats like deeply nested XML or XML that contains malicious
- content.</p>
- </div2>
- </div1>
<div1 id="xml-namespaces">
<head>XML Namespaces</head>
<p>The table below lists XML Namespaces that are used in this document. The choice of any
@@ -2181,7 +2084,16 @@
to add versioning material to primer.
</td>
</tr>
-
+ </tr>
+ <tr>
+ <td>20060924</td>
+ <td>TIB</td>
+ <td>Implemented the
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/35">editorial action 35</loc>
+ to move the Security Considerations section to the Framework document.
+ </td>
+ </tr>
+
</tbody>
</table>
</inform-div1>
Index: ws-policy-framework.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-framework.html,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -d -r1.37 -r1.38
--- ws-policy-framework.html 20 Sep 2006 22:27:16 -0000 1.37
+++ ws-policy-framework.html 25 Sep 2006 03:57:33 -0000 1.38
@@ -72,7 +72,7 @@
<h2><a name="status">Status of this Document</a></h2><p><strong>This document is an editors' copy that has
no official standing.</strong></p><p></p></div>
<hr><div class="toc">
-<h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#tocRange">Introduction</a><br> 1.1 <a href="#Example">Example</a><br>2. <a href="#Notation_Terminilogy">Notations and Terminology</a><br> 2.1 <a href="#Notational_Conventions">Notational Conventions</a><br> 2.2 <a href="#Extensibility">Extensibility</a><br> 2.3 <a href="#XML_Namespaces">XML Namespaces</a><br> 2.4 <a href="#Terminology">Terminology</a><br>3. <a href="#Policy_Model">Policy Model</a><br> 3.1 <a href="#rPolicy_Assertion">Policy Assertion</a><br> 3.2 <a href="#rPolicy_Alternative">Policy Alternative</a><br> 3.3 <a href="#rPolicy">Policy</a><br> 3.4 <a href="#Web_services">Policies of Entities in a Web Services Based System</a><br>4. <a href="#rPolicy_Expression">Policy Expression</a><br> 4.1 < href="#Normal_Form_Policy_Expression">Normal Form Policy Expression</a><br> 4.2 <a href="#Policy_Identification">Policy Identification</a><br> 4.3 <a href="#Compact_Policy_Expression">Compact Policy Expression</a><br> 4.3.1 <a href="#Optional_Policy_Assertions">Optional Policy Assertions</a><br> 4.3.2 <a href="#Policy_Assertion_Nesting">Policy Assertion Nesting</a><br> 4.3.3 <a href="#Policy_Operators">Policy Operators</a><br> 4.3.4 <a href="#Policy_Inclusion">Policy Inclusion</a><br> 4.4 <a href="#Policy_Intersection">Policy Intersection</a><br>5. <a href="#Security_Considerations">Security Considerations</a><br>6. <a href="#Conformance">Conformance</a><br></p>
+<h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#tocRange">Introduction</a><br> 1.1 <a href="#Example">Example</a><br>2. <a href="#Notation_Terminilogy">Notations and Terminology</a><br> 2.1 <a href="#Notational_Conventions">Notational Conventions</a><br> 2.2 <a href="#Extensibility">Extensibility</a><br> 2.3 <a href="#XML_Namespaces">XML Namespaces</a><br> 2.4 <a href="#Terminology">Terminology</a><br>3. <a href="#Policy_Model">Policy Model</a><br> 3.1 <a href="#rPolicy_Assertion">Policy Assertion</a><br> 3.2 <a href="#rPolicy_Alternative">Policy Alternative</a><br> 3.3 <a href="#rPolicy">Policy</a><br> 3.4 <a href="#Web_services">Policies of Entities in a Web Services Based System</a><br>4. <a href="#rPolicy_Expression">Policy Expression</a><br> 4.1 < href="#Normal_Form_Policy_Expression">Normal Form Policy Expression</a><br> 4.2 <a href="#Policy_Identification">Policy Identification</a><br> 4.3 <a href="#Compact_Policy_Expression">Compact Policy Expression</a><br> 4.3.1 <a href="#Optional_Policy_Assertions">Optional Policy Assertions</a><br> 4.3.2 <a href="#Policy_Assertion_Nesting">Policy Assertion Nesting</a><br> 4.3.3 <a href="#Policy_Operators">Policy Operators</a><br> 4.3.4 <a href="#Policy_Inclusion">Policy Inclusion</a><br> 4.4 <a href="#Policy_Intersection">Policy Intersection</a><br>5. <a href="#Security_Considerations">Security Considerations</a><br> 5.1 <a href="#information-disclosure-threats">Information Disclosure Threats</a><br> 5.2 <a href"#spoofing-and-tampering-threats">Spoofing and Tampering Threats</a><br> 5.3 <a href="#downgrade-threats">Downgrade Threats</a><br> 5.4 <a href="#repudiation-threats">Repudiation Threats</a><br> 5.5 <a href="#denial-of-service-threats">Denial of Service Threats</a><br> 5.6 <a href="#general-xml-considerations">General XML Considerations</a><br>6. <a href="#Conformance">Conformance</a><br></p>
<h3><a name="appendix" id="appendix">Appendices</a></h3><p class="toc">A. <a href="#References">References</a><br> A.1 <a href="#Normative-References">Normative References</a><br> A.2 <a href="#Informative-References">Other References</a><br>B. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br>C. <a href="#change-description">Changes in this Version of the Document</a> (Non-Normative)<br>D. <a href="#change-log">Web Services Policy 1.5 - Framework Change Log</a> (Non-Normative)<br></p></div><hr><div class="body">
<div class="div1">
@@ -327,21 +327,111 @@
</p>
<p>We introduce the following terms that are used throughout this document:</p>
- <dl><dt class="label"><a href="#nested_policy_expression">nested policy expression</a></dt><dd><p>A <b>nested policy expression</b> is a <a title="policy expression" href="#policy_expression">policy expression</a> that is an Element Information Item in the <strong>[children]</strong> property of a <a title="policy assertion" href="#policy_assertion">policy assertion</a>.</p></dd><dt class="label"><a href="#policy">policy</a></dt><dd><p>A <b>policy</b> is a collection of
- <a title="policy alternative" href="#policy_alternative">policy alternatives</a>, </p></dd><dt class="label"><a href="#policy_alternative">policy alternative</a></dt><dd><p>a <b>policy alternative</b>
- is a collection of <a title="policy assertion" href="#policy_assertion">policy assertions</a>.</p></dd><dt class="label"><a href="#policy_assertion">policy assertion</a></dt><dd><p>A <b>policy assertion</b>
- represents an individual requirement, capability, or other property of a behavior.</p></dd><dt class="label"><a href="#policy_assertion_parameter">policy assertion parameter</a></dt><dd><p>A <b>policy assertion parameter</b>
- qualifies the behavior indicated by a <a title="policy assertion" href="#policy_assertion">policy assertion</a>.</p></dd><dt class="label"><a href="#policy_assertion_type">policy assertion type</a></dt><dd><p>A <b>policy assertion type</b>
+
+<dl>
+
+ <dt class="label">
+ <a href="#nested_policy_expression">nested policy expression</a>
+ </dt>
+ <dd>
+ <p>A <b>nested policy expression</b> is a <a title="policy expression" href="#policy_expression">policy expression</a> that is an Element Information Item in the <strong>[children]</strong> property of a <a title="policy assertion" href="#policy_assertion">policy assertion</a>.</p>
+ </dd>
+
+
+ <dt class="label">
+ <a href="#policy">policy</a>
+ </dt>
+ <dd>
+ <p>A <b>policy</b> is a collection of
+ <a title="policy alternative" href="#policy_alternative">policy alternatives</a>, </p>
+ </dd>
+
+
+ <dt class="label">
+ <a href="#policy_alternative">policy alternative</a>
+ </dt>
+ <dd>
+ <p>a <b>policy alternative</b>
+ is a collection of <a title="policy assertion" href="#policy_assertion">policy assertions</a>.</p>
+ </dd>
+
+
+ <dt class="label">
+ <a href="#policy_assertion">policy assertion</a>
+ </dt>
+ <dd>
+ <p>A <b>policy assertion</b>
+ represents an individual requirement, capability, or other property of a behavior.</p>
+ </dd>
+
+
+ <dt class="label">
+ <a href="#policy_assertion_parameter">policy assertion parameter</a>
+ </dt>
+ <dd>
+ <p>A <b>policy assertion parameter</b>
+ qualifies the behavior indicated by a <a title="policy assertion" href="#policy_assertion">policy assertion</a>.</p>
+ </dd>
+
+
+ <dt class="label">
+ <a href="#policy_assertion_type">policy assertion type</a>
+ </dt>
+ <dd>
+ <p>A <b>policy assertion type</b>
represents a class of <a title="policy assertion" href="#policy_assertion">policy assertions</a> and implies a
- schema for the assertion and assertion-specific semantics.</p></dd><dt class="label"><a href="#policy_attachment">policy attachment</a></dt><dd><p>A
+ schema for the assertion and assertion-specific semantics.</p>
+ </dd>
+
+
+ <dt class="label">
+ <a href="#policy_attachment">policy attachment</a>
+ </dt>
+ <dd>
+ <p>A
<b>policy attachment</b> is a mechanism for associating
- <a title="policy" href="#policy">policy</a> with one or more <a title="policy scope" href="#policy_scope">policy scopes</a>.</p></dd><dt class="label"><a href="#policy_expression">policy expression</a></dt><dd><p>A <b>policy expression</b>
+ <a title="policy" href="#policy">policy</a> with one or more <a title="policy scope" href="#policy_scope">policy scopes</a>.</p>
+ </dd>
+
+
+ <dt class="label">
+ <a href="#policy_expression">policy expression</a>
+ </dt>
+ <dd>
+ <p>A <b>policy expression</b>
is an XML Infoset representation of a <a title="policy" href="#policy">policy</a>,
- either in a normal form or in an equivalent compact form.</p></dd><dt class="label"><a href="#policy_scope">policy scope</a></dt><dd><p>A <b>policy scope</b> is a collection of
- <a title="policy subject" href="#policy_subject">policy subjects</a> to which a policy may apply.</p></dd><dt class="label"><a href="#policy_subject">policy subject</a></dt><dd><p>A <b>policy subject</b> is an entity
+ either in a normal form or in an equivalent compact form.</p>
+ </dd>
+
+
+ <dt class="label">
+ <a href="#policy_scope">policy scope</a>
+ </dt>
+ <dd>
+ <p>A <b>policy scope</b> is a collection of
+ <a title="policy subject" href="#policy_subject">policy subjects</a> to which a policy may apply.</p>
+ </dd>
+
+
+ <dt class="label">
+ <a href="#policy_subject">policy subject</a>
+ </dt>
+ <dd>
+ <p>A <b>policy subject</b> is an entity
(e.g., an endpoint, message, resource, interaction) with which a
- <a title="policy" href="#policy">policy</a> can be associated. </p></dd><dt class="label"><a href="#policy_vocabulary">policy vocabulary</a></dt><dd><p>A <b>policy vocabulary</b> is the set of all
- <a title="policy assertion type" href="#policy_assertion_type">policy assertion types</a> used in a policy.</p></dd></dl>
+ <a title="policy" href="#policy">policy</a> can be associated. </p>
+ </dd>
+
+
+ <dt class="label">
+ <a href="#policy_vocabulary">policy vocabulary</a>
+ </dt>
+ <dd>
+ <p>A <b>policy vocabulary</b> is the set of all
+ <a title="policy assertion type" href="#policy_assertion_type">policy assertion types</a> used in a policy.</p>
+ </dd>
+
+</dl>
</div>
</div>
<div class="div1">
@@ -1194,7 +1284,16 @@
<h3><a name="Policy_Intersection"></a>4.4 Policy Intersection</h3>
<p>Policy intersection is useful when two or more parties express <a title="policy" href="#policy">policy</a> and want to limit the <a title="policy alternative" href="#policy_alternative">policy alternatives</a> to those that are mutually compatible. For example, when a requester and a provider express requirements on a message exchange, intersection identifies compatible policy alternatives (if any) included in both requester and provider policies. Intersection is a commutative, associative function that takes two policies and returns a policy.</p>
-<p>Because the set of behaviors indicated by a <a title="policy alternative" href="#policy_alternative">policy alternative</a> depends on the domain-specific semantics of the collected assertions, determining whether two policy alternatives are compatible generally involves domain-specific processing. As a first approximation, an algorithm is defined herein that approximates compatibility in a domain-independent manner; specifically, for two policy alternatives to be compatible, they must at least have the same vocabulary (see Section <a href="#rPolicy_Alternative"><b>3.2 Policy Alternative</b></a>).</p>
+<p>Because the set of behaviors indicated by a <a title="policy alternative" href="#policy_alternative">policy
+alternative</a> depends on the domain-specific semantics of the collected assertions,
+determining whether two policy alternatives are compatible generally involves
+domain-specific processing. If a domain-specific intersection processing algorithm
+is required will be known from the QNames of the specific <a title="policy assertion type" href="#policy_assertion_type">assertion types</a>
+involved in the policy alternatives. As a first approximation, an algorithm is defined herein
+that approximates compatibility in a domain-independent manner; specifically,
+for two policy alternatives to be compatible, they must at least have the same
+vocabulary (see Section <a href="#rPolicy_Alternative"><b>3.2 Policy Alternative</b></a>).
+</p>
<ul>
<li><p>Two <a title="policy assertion" href="#policy_assertion">policy assertions</a> are compatible if they have the same <a title="policy assertion type" href="#policy_assertion_type">type</a> and</p></li>
<li><p>If either assertion contains a nested <a title="policy expression" href="#policy_expression">policy expression</a>, the two assertions are compatible if they both have a nested policy expression and the alternative in the nested policy expression of one is compatible with the alternative in the nested policy expression of the other.</p></li>
@@ -1302,6 +1401,107 @@
<p>It should be noted that the mechanisms described in this document
could be secured as part of a SOAP message [<cite><a href="#SOAP11">SOAP 1.1</a></cite>, <cite><a href="#SOAP12">SOAP 1.2 Messaging Framework</a></cite>] using WS-Security [<cite><a href="#WS-Security">WS-Security 2004</a></cite>] or embedded within other
objects using object-specific security mechanisms.</p>
+
+ <p>This section describes the security considerations that service providers, requestors,
+ policy authors, policy assertion authors, and policy implementers need to consider when
+ exposing, consuming and designing policy expressions, authoring policy assertions or
+ implementing policy.</p>
+ <div class="div2">
+
+<h3><a name="information-disclosure-threats"></a>5.1 Information Disclosure Threats</h3>
+ <p>A policy is used to represent the capabilities and requirements of a Web Service.
+ Policies may include sensitive information. Malicious consumers may acquire sensitive
+ information, fingerprint the service and infer service vulnerabilities. These threats can
+ be mitigated by requiring authentication for sensitive information, by omitting sensitive
+ information from the policy or by securing access to the policy. For securing access to
+ policy metadata, policy providers can use mechanisms from other Web Services
+ specifications such as WS-Security and WS-MetadataExchange.</p>
+ </div>
+ <div class="div2">
+
+<h3><a name="spoofing-and-tampering-threats"></a>5.2 Spoofing and Tampering Threats</h3>
+ <p>If a policy expression is unsigned it could be easily tampered with or replaced. To
+ prevent tampering or spoofing of policy, requestors should discard a policy unless it is
+ signed by the provider and presented with sufficient credentials. Requestors should also
+ check that the signer is actually authorized to express policies for the given policy
+ subject.</p>
+ </div>
+ <div class="div2">
+
+<h3><a name="downgrade-threats"></a>5.3 Downgrade Threats</h3>
+ <p>A policy may offer several alternatives that vary from weak to strong set of
+ requirements. An adversary may interfere and remove all the alternatives except the
+ weakest one (say no security requirements). Or, an adversary may interfere and discard
+ this policy and insert a weaker policy previously issued by the same provider. Policy
+ authors or providers can mitigate these threats by sun-setting older or weaker policy
+ alternatives. Requestors can mitigate these threats by discarding policies unless they are
+ signed by the provider.</p>
+ </div>
+ <div class="div2">
+
+<h3><a name="repudiation-threats"></a>5.4 Repudiation Threats</h3>
+ <p>Malicious providers may include policy assertions in its policy whose behavior cannot be
+ verified by examining the wire message from the provider to requestor. In general,
+ requestors have no guarantee that a provider will behave as described in the provider’s
+ policy expression. The provider may not and perform a malicious activity. For example, say
+ the policy assertion is privacy notice information and the provider violates the semantics
+ by disclosing private information. Requestors can mitigate this threat by discarding
+ policy alternatives which include assertions whose behavior cannot be verified by
+ examining the wire message from the provider to requestor. Assertion authors can mitigate
+ this threat by not designing assertions whose behavior cannot be verified using wire
+ messages.</p>
+ </div>
+ <div class="div2">
+
+<h3><a name="denial-of-service-threats"></a>5.5 Denial of Service Threats</h3>
+ <p>Malicious providers may provide a policy expression with a large number of alternatives,
+ a large number of assertions in alternatives, deeply nested policy expressions or chains
+ of PolicyReference elements that expand exponentially (see the chained sample below; this
+ is similar to the well-known DTD entity expansion attack). Policy implementers need to
+ anticipate these rogue providers and use a configurable bound with defaults on number of
+ policy alternatives, number of assertions in an alternative, depth of nested policy
+ expressions, etc.</p>
+ <div class="exampleOuter">
+ <p style="text-align: left" class="exampleHead"><i><span>Example 5-1. </span>Chained Policy Reference Elements</i></p>
+ <div class="exampleInner"><pre><Policy wsu:Id="p1">
+ <PolicyReference URI="#p2"/ >
+ <PolicyReference URI="#p2"/>
+ </Policy>
+
+ <Policy wsu:Id="p2" >
+ <PolicyReference URI="#p3"/>
+ <PolicyReference URI="#p3"/>
+ </Policy>
+
+ <Policy wsu:Id="p3" >
+ <PolicyReference URI="#p4"/>
+ <PolicyReference URI="#p4"/>
+ </Policy>
+
+ <!-- Policy/@wsu:Id p4 through p99 -->
+
+ <Policy wsu:Id="p100" >
+ <PolicyReference URI="#p101"/>
+ <PolicyReference URI="#p101"/>
+ </Policy>
+
+ <Policy wsu:Id="p101" >
+ <mtom:OptimizedMimeSerialization />
+ </Policy></pre></div>
+ </div>
+ <p>Malicious providers may provide a policy expression that includes multiple
+ PolicyReference elements that use a large number of different internet addresses. These
+ may require the consumers to establish a large number of TCP connections. Policy
+ implementers need to anticipate such rogue providers and use a configurable bound with
+ defaults on number of PolicyReference elements per policy expression.</p>
+ </div>
+ <div class="div2">
+
+<h3><a name="general-xml-considerations"></a>5.6 General XML Considerations</h3>
+ <p>Implementers of Web Services policy language should be careful to protect their software
+ against general XML threats like deeply nested XML or XML that contains malicious
+ content.</p>
+ </div>
</div>
<div class="div1">
@@ -1819,6 +2019,24 @@
Add PolicyReference extensibility.
</td>
</tr>
+ <tr>
+ <td rowspan="1" colspan="1">20060921</td>
+ <td rowspan="1" colspan="1">PY</td>
+ <td rowspan="1" colspan="1">Completed action item:
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/29">29</a>
+ for issue
+ <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3577">3577</a>,
+ Semantics of successful intersection determined by domain-specific assertion content.
+ </td>
+ </tr>
+ <tr>
+ <td rowspan="1" colspan="1">20060924</td>
+ <td rowspan="1" colspan="1">TIB</td>
+ <td rowspan="1" colspan="1">Implemented the
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/35">editorial action 35</a>
+ to include the Security Considerations section from the Primer document.
+ </td>
+ </tr>
</tbody>
</table><br>
</div>
Received on Monday, 25 September 2006 03:57:47 UTC