- From: Doug Davis via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 11 May 2010 19:17:03 +0000
- To: public-ws-resource-access-notifications@w3.org
Update of /w3ccvs/WWW/2002/ws/ra/edcopies
In directory hutz:/tmp/cvs-serv16326
Modified Files:
wsenum.html wsenum.xml
Log Message:
9568
Index: wsenum.html
===================================================================
RCS file: /w3ccvs/WWW/2002/ws/ra/edcopies/wsenum.html,v
retrieving revision 1.132
retrieving revision 1.133
diff -u -d -r1.132 -r1.133
--- wsenum.html 5 May 2010 02:42:44 -0000 1.132
+++ wsenum.html 11 May 2010 19:17:00 -0000 1.133
@@ -69,12 +69,15 @@
5.10 <a href="#EndToNotSupported">EndToNotSupported</a><br/>
5.11 <a href="#EmptyFilter">EmptyFilter</a><br/>
6 <a href="#Security">Security Considerations</a><br/>
+ 6.1 <a href="#iddiv2_1_1957">Creating Enumeration Contexts</a><br/>
+ 6.2 <a href="#iddiv2_1_1962">Protecting Enumeration Contexts</a><br/>
+ 6.3 <a href="#iddiv2_1_1969">Endpoint Verification</a><br/>
7 <a href="#metadata">WS-Enumeration Metadata</a><br/>
- 7.1 <a href="#iddiv2_1_2040">Enumeration Assertion</a><br/>
+ 7.1 <a href="#iddiv2_1_1989">Enumeration Assertion</a><br/>
8 <a href="#acks">Acknowledgements</a><br/>
9 <a href="#refs">References</a><br/>
- 9.1 <a href="#iddiv2_1_2147">Normative References</a><br/>
- 9.2 <a href="#iddiv2_1_2333">Informative References</a><br/>
+ 9.1 <a href="#iddiv2_1_2096">Normative References</a><br/>
+ 9.2 <a href="#iddiv2_1_2282">Informative References</a><br/>
</p>
<h3><a name="appendices" id="appendices"/>Appendices</h3><p class="toc">A <a href="#schema">XML Schema</a><br/>
B <a href="#WSDL">WSDL</a><br/>
@@ -1213,97 +1216,76 @@
reason, will never evaluate to true.
</p><table border="1"><tbody><tr><td><b>[Code]</b></td><td>s12:Sender</td></tr><tr><td><b>[Subcode]</b></td><td>wsen:EmptyFilter</td></tr><tr><td><b>[Reason]</b></td><td>The wsen:Filter would result in zero data items.</td></tr><tr><td><b>[Detail]</b></td><td><em> The wsen:Filter value. </em></td></tr></tbody></table></div></div><div class="div1">
<h2><a name="Security" id="Security"/>6 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 consumer is issuing multiple messages to a
- Web service, such as when a consumer is enumerating a data source,
- it is RECOMMENDED that a security context be established using the
- mechanisms described in <a href="#WSSecureConversation">[WS-SecureConversation]</a>. It is often
- appropriate to establish a security context that is used both for
- the initiation of enumeration (i.e., the Enumerate request or an
- equivalent service-specific request) and the actual enumeration
- itself (i.e., the Pull requests). It is further RECOMMENDED that if
- shared secrets are used, message-specific derived keys SHOULD be
- used to protect the secret from crypto attacks.
- </p><p>
- The access control semantics of data sources is
- out-of-scope of this specification and are specific to each data
- source. Similarly, any protection mechanisms on data
- source independent of their 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-Enumeration 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-Enumeration. However, once those
+ requirements have been satisfied within a given operational context,
+ the addition of WS-Enumeration to this operational context can not
+ undermine the fulfillment of those requirements; the use of
+ WS-Enumeration SHOULD NOT create additional attack vectors within
+ an otherwise secure system.
</p><p>
- While a comprehensive set 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_1957" id="iddiv2_1_1957"/>6.1 Creating Enumeration Contexts</h3><p>
+ An enumeration represents a logical cursor through a sequence of
+ data items. If the information in these items is sensitive, it is
+ advisable to for Data Sources to authenticate and authorize Consumers
+ as part of the processing of the Enumerate request. Note that a
+ Data Source might authorize retrievals on a per-item basis after the
+ enumeration has been created. This might be necessary in cases where
+ the sensitivity of the information requested might not be known at
+ the time the Enumerate request is processed or varies during the
+ lifetime of the enumeration.
+ </p></div><div class="div2">
+<h3><a name="iddiv2_1_1962" id="iddiv2_1_1962"/>6.2 Protecting Enumeration Contexts</h3><p>
+ Once created, it is advisable to treat Enumeration Contexts as
+ protected resources. Renew, GetStatus, and Release requests ought to
+ be authenticated and authorized (for example, the identity of the
+ requester ought to be checked against the identity of the entity
+ that performed the original Enumerate request). Likewise
+ EnumerationEnd messages ought to be authenticated and authorized
+ (for example, the identity of the sender ought to be checked against
+ the identity the entity that sent the original EnumerateResponse message).
+ Note that authentication and authorization policies (i.e. the rules
+ that define which entities are allowed to perform which requests and
+ the mechanisms by which the identities of these entities are
+ discovered and verified) are particular to individual deployments.
+ </p><p>
+ Enumeration Contexts are also sensitive because of the way they are
+ used to maintain or reference the state of active Enumerations.
+ Attackers able to snoop or guess the value of an Enumeration Context
+ could use this information to Pull data items in that Enumeration.
+ To defend against the misuse of snooped/guessed Enumeration Contexts,
+ Data Sources are advised to authenticate and authorize clients
+ sending Pull requests.
+ </p></div><div class="div2">
+<h3><a name="iddiv2_1_1969" id="iddiv2_1_1969"/>6.3 Endpoint Verification</h3><p>
+ Data Source implementations that perform validity checks on the
+ EndTo EPR used in the Enumerate request are advised that such checks
+ can be misused to obtain information about a target network. For
+ example, suppose a Data Source implementation verifies the address
+ of EndTo EPRs by attempting to create a connection to this EPR's
+ address and faulting the Enumerate request if a connection cannot
+ be created. When deployed within a DMZ, such a Data Source could be
+ exploited by a malicious Consumer to probe for other, non-visible
+ hosts by guessing target addresses and using them in Enumerate requests.
+ Note that, even if the returned fault does not provide connection
+ information, the time the Data Source spends processing the
+ Enumerate request might betray the existence or non-existence of a
+ host at the target address.
+ </p><p>
+ Implementations that perform validity checks on the EndTo EPR are
+ advised to provide a means to disable such checks in environments
+ where these types of attacks are an issue.
+ </p></div></div><div class="div1">
<h2><a name="metadata" id="metadata"/>7 WS-Enumeration Metadata</h2><p>
An endpoint MAY indicate its support of WS-Enumeration, or its features,
by including the WS-Enumeration DataSource Policy assertion within its
@@ -1327,7 +1309,7 @@
that indicate a particular security mechanism used to protect
the WS-Enumeration operations supported by this endpoint.
</p><div class="div2">
-<h3><a name="iddiv2_1_2040" id="iddiv2_1_2040"/>7.1 Enumeration Assertion</h3><p>
+<h3><a name="iddiv2_1_1989" id="iddiv2_1_1989"/>7.1 Enumeration Assertion</h3><p>
Services indicate support for the WS-Enumeration's definition of a
data source through the use of the Web Services
Policy - Framework <a href="#wspolicy">[WS-Policy]</a> and Web Services Policy -
@@ -1430,7 +1412,7 @@
Yves Lafon (W3C/ERCIM).
</p></div><div class="div1">
<h2><a name="refs" id="refs"/>9 References</h2><div class="div2">
-<h3><a name="iddiv2_1_2147" id="iddiv2_1_2147"/>9.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_2096" id="iddiv2_1_2096"/>9.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.
@@ -1502,7 +1484,7 @@
, J. Clark, S. DeRose, Editors.
World Wide Web Consortium (W3C), 16 November 1999.
Available at <a href="http://www.w3.org/TR/xpath">http://www.w3.org/TR/xpath</a>.</dd></dl></div><div class="div2">
-<h3><a name="iddiv2_1_2333" id="iddiv2_1_2333"/>9.2 Informative References</h3><dl><dt class="label"><a name="MEX" id="MEX"/>WS-MetadataExchange</dt><dd><a href="http://www.w3.org/TR/ws-metadata-exchange"><cite>
+<h3><a name="iddiv2_1_2282" id="iddiv2_1_2282"/>9.2 Informative References</h3><dl><dt class="label"><a name="MEX" id="MEX"/>WS-MetadataExchange</dt><dd><a href="http://www.w3.org/TR/ws-metadata-exchange"><cite>
W3C Working Group Draft, "Web Services Metadata Exchange
(WS-MetadataExchange) 1.1"
</cite></a>
@@ -2130,4 +2112,5 @@
<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=9543">9543</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=9568">9568</a></td></tr></tbody></table></div></div></body></html>
\ No newline at end of file
Index: wsenum.xml
===================================================================
RCS file: /w3ccvs/WWW/2002/ws/ra/edcopies/wsenum.xml,v
retrieving revision 1.123
retrieving revision 1.124
diff -u -d -r1.123 -r1.124
--- wsenum.xml 5 May 2010 02:42:44 -0000 1.123
+++ wsenum.xml 11 May 2010 19:17:01 -0000 1.124
@@ -2283,149 +2283,99 @@
<head>Security Considerations</head>
<p>
- It is strongly RECOMMENDED that the
- communication between services be secured using the mechanisms
- described in <bibref ref="WSSecurity"/>.
- </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 consumer is issuing multiple messages to a
- Web service, such as when a consumer is enumerating a data source,
- it is RECOMMENDED that a security context be established using the
- mechanisms described in <bibref ref="WSSecureConversation"/>. It is often
- appropriate to establish a security context that is used both for
- the initiation of enumeration (i.e., the Enumerate request or an
- equivalent service-specific request) and the actual enumeration
- itself (i.e., the Pull requests). It is further RECOMMENDED that if
- shared secrets are used, message-specific derived keys SHOULD be
- used to protect the secret from crypto attacks.
- </p>
- <p>
- The access control semantics of data sources is
- out-of-scope of this specification and are specific to each data
- source. Similarly, any protection mechanisms on data
- source independent of their 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-Enumeration 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-Enumeration. However, once those
+ requirements have been satisfied within a given operational context,
+ the addition of WS-Enumeration to this operational context can not
+ undermine the fulfillment of those requirements; the use of
+ WS-Enumeration SHOULD NOT create additional attack vectors within
+ an otherwise secure system.
</p>
+
<p>
- While a comprehensive set 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.
+ 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>
- <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>
+ <div2>
+ <head>Creating Enumeration Contexts</head>
- <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>
+ <p>
+ An enumeration represents a logical cursor through a sequence of
+ data items. If the information in these items is sensitive, it is
+ advisable to for Data Sources to authenticate and authorize Consumers
+ as part of the processing of the Enumerate request. Note that a
+ Data Source might authorize retrievals on a per-item basis after the
+ enumeration has been created. This might be necessary in cases where
+ the sensitivity of the information requested might not be known at
+ the time the Enumerate request is processed or varies during the
+ lifetime of the enumeration.
+ </p>
+ </div2>
- <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>
+ <div2>
+ <head>Protecting Enumeration Contexts</head>
- <item>
- <p>
- <emph>Message disclosure</emph>
- - Confidentiality is preserved
- by encrypting sensitive data using WS-Security.
- </p>
- </item>
+ <p>
+ Once created, it is advisable to treat Enumeration Contexts as
+ protected resources. Renew, GetStatus, and Release requests ought to
+ be authenticated and authorized (for example, the identity of the
+ requester ought to be checked against the identity of the entity
+ that performed the original Enumerate request). Likewise
+ EnumerationEnd messages ought to be authenticated and authorized
+ (for example, the identity of the sender ought to be checked against
+ the identity the entity that sent the original EnumerateResponse message).
+ Note that authentication and authorization policies (i.e. the rules
+ that define which entities are allowed to perform which requests and
+ the mechanisms by which the identities of these entities are
+ discovered and verified) are particular to individual deployments.
+ </p>
- <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>
+ <p>
+ Enumeration Contexts are also sensitive because of the way they are
+ used to maintain or reference the state of active Enumerations.
+ Attackers able to snoop or guess the value of an Enumeration Context
+ could use this information to Pull data items in that Enumeration.
+ To defend against the misuse of snooped/guessed Enumeration Contexts,
+ Data Sources are advised to authenticate and authorize clients
+ sending Pull requests.
+ </p>
+ </div2>
- <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>
+ <div2>
+ <head>Endpoint Verification</head>
- <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>
+ <p>
+ Data Source implementations that perform validity checks on the
+ EndTo EPR used in the Enumerate request are advised that such checks
+ can be misused to obtain information about a target network. For
+ example, suppose a Data Source implementation verifies the address
+ of EndTo EPRs by attempting to create a connection to this EPR's
+ address and faulting the Enumerate request if a connection cannot
+ be created. When deployed within a DMZ, such a Data Source could be
+ exploited by a malicious Consumer to probe for other, non-visible
+ hosts by guessing target addresses and using them in Enumerate requests.
+ Note that, even if the returned fault does not provide connection
+ information, the time the Data Source spends processing the
+ Enumerate request might betray the existence or non-existence of a
+ host at the target address.
+ </p>
+ <p>
+ Implementations that perform validity checks on the EndTo EPR are
+ advised to provide a means to disable such checks in environments
+ where these types of attacks are an issue.
+ </p>
+ </div2>
- <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">
@@ -4040,6 +3990,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=9568">9568</loc>
+ </td>
+ </tr>
</tbody>
</table>
</div1>
Received on Tuesday, 11 May 2010 19:17:05 UTC