W3C home > Mailing lists > Public > public-ws-resource-access-notifications@w3.org > May 2010

WWW/2002/ws/ra/edcopies wsenum.html,1.132,1.133 wsenum.xml,1.123,1.124

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
Message-Id: <E1OBuwx-0004I4-30@lionel-hutz.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 @@
 &nbsp;&nbsp;&nbsp;5.10 <a href="#EndToNotSupported">EndToNotSupported</a><br/>
 &nbsp;&nbsp;&nbsp;5.11 <a href="#EmptyFilter">EmptyFilter</a><br/>
 6 <a href="#Security">Security Considerations</a><br/>
+&nbsp;&nbsp;&nbsp;6.1 <a href="#iddiv2_1_1957">Creating Enumeration Contexts</a><br/>
+&nbsp;&nbsp;&nbsp;6.2 <a href="#iddiv2_1_1962">Protecting Enumeration Contexts</a><br/>
+&nbsp;&nbsp;&nbsp;6.3 <a href="#iddiv2_1_1969">Endpoint Verification</a><br/>
 7 <a href="#metadata">WS-Enumeration Metadata</a><br/>
-&nbsp;&nbsp;&nbsp;7.1 <a href="#iddiv2_1_2040">Enumeration Assertion</a><br/>
+&nbsp;&nbsp;&nbsp;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/>
-&nbsp;&nbsp;&nbsp;9.1 <a href="#iddiv2_1_2147">Normative References</a><br/>
-&nbsp;&nbsp;&nbsp;9.2 <a href="#iddiv2_1_2333">Informative References</a><br/>
+&nbsp;&nbsp;&nbsp;9.1 <a href="#iddiv2_1_2096">Normative References</a><br/>
+&nbsp;&nbsp;&nbsp;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>&lt;wsa:ReferenceParameters&gt;</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>&lt;wsa:ReferenceParameters&gt;</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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 May 2010 19:17:05 GMT