W3C home > Mailing lists > Public > public-ws-policy-eds@w3.org > September 2006

2006/ws/policy ws-policy-primer.xml,1.6,1.7 ws-policy-framework.xml,1.50,1.51 ws-policy-framework.html,1.37,1.38

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
Message-Id: <E1GRhb6-0007Qb-TV@lionel-hutz.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">&lt;Policy wsu:Id="p1"&gt;
+                &lt;PolicyReference URI="#p2"/ &gt;
+                &lt;PolicyReference URI="#p2"/&gt;
+                &lt;/Policy&gt;
+                
+                &lt;Policy wsu:Id="p2" &gt;
+                &lt;PolicyReference URI="#p3"/&gt;
+                &lt;PolicyReference URI="#p3"/&gt;
+                &lt;/Policy&gt;
+                
+                &lt;Policy wsu:Id="p3" &gt;
+                &lt;PolicyReference URI="#p4"/&gt;
+                &lt;PolicyReference URI="#p4"/&gt;
+                &lt;/Policy&gt;
+                
+                &lt;!-- Policy/@wsu:Id p4 through p99 --&gt;
+                
+                &lt;Policy wsu:Id="p100" &gt;
+                &lt;PolicyReference URI="#p101"/&gt;
+                &lt;PolicyReference URI="#p101"/&gt;
+                &lt;/Policy&gt;
+                
+                &lt;Policy wsu:Id="p101" &gt;
+                &lt;mtom:OptimizedMimeSerialization /&gt;
+                &lt;/Policy&gt;</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">&lt;Policy wsu:Id="p1"&gt;
-  &lt;PolicyReference URI="#p2"/ &gt;
-  &lt;PolicyReference URI="#p2"/&gt;
-&lt;/Policy&gt;
-        
-&lt;Policy wsu:Id="p2" &gt;
-  &lt;PolicyReference URI="#p3"/&gt;
-  &lt;PolicyReference URI="#p3"/&gt;
-&lt;/Policy&gt;
-        
-&lt;Policy wsu:Id="p3" &gt;
-  &lt;PolicyReference URI="#p4"/&gt;
-  &lt;PolicyReference URI="#p4"/&gt;
-&lt;/Policy&gt;
-        
-&lt;!-- Policy/@wsu:Id p4 through p99 --&gt;
-        
-&lt;Policy wsu:Id="p100" &gt;
-  &lt;PolicyReference URI="#p101"/&gt;
-  &lt;PolicyReference URI="#p101"/&gt;
-&lt;/Policy&gt;
-        
-&lt;Policy wsu:Id="p101" &gt;
-  &lt;mtom:OptimizedMimeSerialization /&gt;
-&lt;/Policy&gt;</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>&nbsp;&nbsp;&nbsp;&nbsp;1.1 <a href="#Example">Example</a><br>2. <a href="#Notation_Terminilogy">Notations and Terminology</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.1 <a href="#Notational_Conventions">Notational Conventions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.2 <a href="#Extensibility">Extensibility</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.3 <a href="#XML_Namespaces">XML Namespaces</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.4 <a href="#Terminology">Terminology</a><br>3. <a href="#Policy_Model">Policy Model</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.1 <a href="#rPolicy_Assertion">Policy Assertion</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.2 <a href="#rPolicy_Alternative">Policy Alternative</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.3 <a href="#rPolicy">Policy</a><br>&nbsp;&nbsp;&nbsp;&nbsp;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>&nbsp;&nbsp;&nbsp;&nbsp;4.1 < href="#Normal_Form_Policy_Expression">Normal Form Policy Expression</a><br>&nbsp;&nbsp;&nbsp;&nbsp;4.2 <a href="#Policy_Identification">Policy Identification</a><br>&nbsp;&nbsp;&nbsp;&nbsp;4.3 <a href="#Compact_Policy_Expression">Compact Policy Expression</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.3.1 <a href="#Optional_Policy_Assertions">Optional Policy Assertions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.3.2 <a href="#Policy_Assertion_Nesting">Policy Assertion Nesting</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.3.3 <a href="#Policy_Operators">Policy Operators</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.3.4 <a href="#Policy_Inclusion">Policy Inclusion</a><br>&nbsp;&nbsp;&nbsp;&nbsp;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>&nbsp;&nbsp;&nbsp;&nbsp;1.1 <a href="#Example">Example</a><br>2. <a href="#Notation_Terminilogy">Notations and Terminology</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.1 <a href="#Notational_Conventions">Notational Conventions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.2 <a href="#Extensibility">Extensibility</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.3 <a href="#XML_Namespaces">XML Namespaces</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.4 <a href="#Terminology">Terminology</a><br>3. <a href="#Policy_Model">Policy Model</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.1 <a href="#rPolicy_Assertion">Policy Assertion</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.2 <a href="#rPolicy_Alternative">Policy Alternative</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.3 <a href="#rPolicy">Policy</a><br>&nbsp;&nbsp;&nbsp;&nbsp;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>&nbsp;&nbsp;&nbsp;&nbsp;4.1 < href="#Normal_Form_Policy_Expression">Normal Form Policy Expression</a><br>&nbsp;&nbsp;&nbsp;&nbsp;4.2 <a href="#Policy_Identification">Policy Identification</a><br>&nbsp;&nbsp;&nbsp;&nbsp;4.3 <a href="#Compact_Policy_Expression">Compact Policy Expression</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.3.1 <a href="#Optional_Policy_Assertions">Optional Policy Assertions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.3.2 <a href="#Policy_Assertion_Nesting">Policy Assertion Nesting</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.3.3 <a href="#Policy_Operators">Policy Operators</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.3.4 <a href="#Policy_Inclusion">Policy Inclusion</a><br>&nbsp;&nbsp;&nbsp;&nbsp;4.4 <a href="#Policy_Intersection">Policy Intersection</a><br>5. <a href="#Security_Considerations">Security Considerations</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.1 <a href="#information-disclosure-threats">Information Disclosure Threats</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.2 <a href"#spoofing-and-tampering-threats">Spoofing and Tampering Threats</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.3 <a href="#downgrade-threats">Downgrade Threats</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.4 <a href="#repudiation-threats">Repudiation Threats</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.5 <a href="#denial-of-service-threats">Denial of Service Threats</a><br>&nbsp;&nbsp;&nbsp;&nbsp;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>&nbsp;&nbsp;&nbsp;&nbsp;A.1 <a href="#Normative-References">Normative References</a><br>&nbsp;&nbsp;&nbsp;&nbsp;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&rsquo;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>&lt;Policy wsu:Id="p1"&gt;
+                &lt;PolicyReference URI="#p2"/ &gt;
+                &lt;PolicyReference URI="#p2"/&gt;
+                &lt;/Policy&gt;
+                
+                &lt;Policy wsu:Id="p2" &gt;
+                &lt;PolicyReference URI="#p3"/&gt;
+                &lt;PolicyReference URI="#p3"/&gt;
+                &lt;/Policy&gt;
+                
+                &lt;Policy wsu:Id="p3" &gt;
+                &lt;PolicyReference URI="#p4"/&gt;
+                &lt;PolicyReference URI="#p4"/&gt;
+                &lt;/Policy&gt;
+                
+                &lt;!-- Policy/@wsu:Id p4 through p99 --&gt;
+                
+                &lt;Policy wsu:Id="p100" &gt;
+                &lt;PolicyReference URI="#p101"/&gt;
+                &lt;PolicyReference URI="#p101"/&gt;
+                &lt;/Policy&gt;
+                
+                &lt;Policy wsu:Id="p101" &gt;
+                &lt;mtom:OptimizedMimeSerialization /&gt;
+                &lt;/Policy&gt;</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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:27:49 UTC