Subject: Re: [CDNi] URI Signing for CDNI Working Group Draft

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Fri, 2 May 2014 07:11:14 +0000

Hi Ben,

Thanks for you review. Sorry for taking so long to respond to your comments. 

> -----Original Message-----
> From: CDNi [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
> Sent: dinsdag 25 maart 2014 12:03
> To: Daryl Malas
> Cc: [email-masked]
> Subject: Re: [CDNi] URI Signing for CDNI Working Group Draft
> 
> Daryl, Authors,
> 
> I gave the draft a quick read. It seems a reasonable starting point.
> 
> While I was reading the draft I noticed a couple of things in it that I think are
> worth raising:
> 
> 1) In section 2 the draft says "Any attributes appended in such way after the
> URI Signature has been calculated are not validated for the purpose of
> content access authorization."
> 
> If additional query parameters can be appended to the URI which are not
> validated, could a UA obtain content that it isn't authorised to obtain by
> adding additional query parameters? It seems like something that could be
> worth discussing in the security considerations section?
> 

I'm not sure I understand you correctly. Any parameters added by the UA after the URI Signature are not taken into account during the signing process. As such, there is no way for these parameters to affect the outcome of the validation process. The only way for the UA to affect the validation outcome would be to change the IR Signing Package Attribute, however, this would cause the signature to be invalid. 

> 2) Section 2.2 allows the KeyID to be included in the Signed URI. This also
> seems like it might open a security hole as a malicious UA could strip the
> original URISigningPackage attribute, sign the URI with a Key under its control
> (possibly altering other things like the actual URI or expiry time) and include
> the appropriate KeyID for that new Key in the new URISigningPackage.
> 
> Is there a use case for signalling the KeyID within the Signed URI itself?

The use case for signaling the KeyID is the uCDN allowing multiple keys to be used in the metadata. In order to signal the used Key to the dCDN, the KeyID field is used.

Let's assume that for a given content item, the uCDN allows five different keys to be used (as announced in the metadata). You're right that if the UA would somehow have access to one of these five keys, and the associated keyID, it could recalculate the URISigningPackage attribute. However, I don't think this problem stems from the use of the KeyID field. Even if there would be only one key, and this key would be leaked, then the UA could also resign the UA. So the question is, is the chance of a given key leaking bigger if it is part of a set of allowed keys instead of the only allowed key?

> 
> 3) Regarding hash functions & digital signature algorithms, the draft hints at
> allowing several options for each and defines a default in case a particular
> algorithm is not specified in the URISigningPackage.
> 
> This seems a bit overkill to me. To aid inter-operability, I think it would be
> better to specify a single algorithm for each unless there are use cases for
> requiring support for more than one algorithm in the first version defined in
> the draft?
> 

Are you saying you would prefer to keep the HF and DSA fields but only define one possible value for them in this document, or are you saying you would prefer to remove these fields and just specify a single mandatory hash function and DS algorithm? Personally, I think it is useful to have the option of signaling different hash functions or DS algorithms. 

Thanks,

Ray

> Regards
> Ben
> 
> 
> On 6 Mar 2014, at 15:34, Daryl Malas wrote:
> 
> > All,
> >
> > During today's working group meeting, we agreed the latest draft revision
> of this draft (http://tools.ietf.org/html/draft-leung-cdni-uri-signing-05) is
> substantial for us to adopt it as a working group item.  However, Francois and
> I did not feel comfortable conducting a "Hum," since there were not a lot of
> people present who had read the draft.  This draft was proposed in response
> to the following charter item:
> >
> > A specification for "CDNI URI Signing". This document will specify a
> > mechanism that allows interconnected CDNs to support access control by
> > signing content URIs. This may involve extensions to the CDNI
> > interfaces (e.g. CDNI Metadata interface, CDNI Logging interface).
> >
> > In addition, the working group has the following milestone:
> >
> > Sep 2014 - Submit specification of URI Signing for CDNI to IESG as
> > Proposed Standard
> >
> > With this in mind, we are requesting people read the draft in preparation
> for this draft to be accepted as a working group item, which will occur on
> March 21st.  If anyone has any major concerns with this, please post
> comments and concerns to the list.
> >
> > Regards,
> >
> > Daryl & Francois
> >
> >
> >
> > _______________________________________________
> > CDNi mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/cdni
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 12 May 2014 17:55:33 +0100

Ray,

See inline.

> I'm not sure I understand you correctly. Any parameters added by the UA after the URI Signature are not taken into account during the signing process. As such, there is no way for these parameters…

Section 3 of the draft states "The entire URI except the "scheme name" part is protected by the URI signature.” But if someone can append additional query parameters to a signed URI and still have it be considered “correctly signed” by a dCDN then the proposed mechanism is not protecting “the entire URI”.

That aside, as it stands, as specified in the draft I believe it is possible to do the following:

Take a URI, e.g.
http://videos.example/videos?title=batman

and sign it to get something like

http://videos.example/videos?title=batman&<URI Signing stuff>

then present to a dCDN the following URI

http://videos.example/videos?title=batman&<URI Signing stuff>&quality=HD

which will correctly validate but lead to a dCDN acquiring/delivering

http://videos.example/videos?title=batman&quality=HD

which, even though it passes URI signing validation, is a different URI/resource to the one that was originally signed.

> Let's assume that for a given content item, the uCDN allows five different keys to be used (as announced in the metadata). You're right that if the UA would somehow have access to one of these five…

The attack surface could be larger than leaked keys. E.g. if the 5 keys the uCDN says are allowed came from different content providers, then the key does’t have to leak anywhere, an enterprising individual with legitimate knowledge of  CSP1’s key could use CSP1’s key to sign URIs and get hold of content from CSP2.

For the use case presented I think there is a better/easier way to solve it rather than have each UA->dCDN request include which key to use.

What I’d propose is:
- Within CDNI Metadata the URI signing keys are associated with the content to which they apply.

- The CDNI Metadata can contain >1 key for a given piece of content.

- If any of the keys included in the relevant CDNI Metadata correctly validate the URI, then it is valid.

That way a CSP can provide/use multiple keys if they want, there is no need to signal the keyID to be used in the URI itself (so absolutely no ability for a User Agent to affect it in any way), and you can do key-rollover without having to co-ordinate KeyIDs between the party responsible for signing the URI (the uCDN/CSP probably) and the party responsible for validating them (the dCDN).

> Are you saying you would prefer to keep the HF and DSA fields but only define one possible value for them in this document, or are you saying you would prefer to remove these fields and just specif…

I am OK with leaving in the hooks for extensibility.

I don’t like the idea of specifying >1 hash function/digital signature algorithm in this document.

This document is defining a new URI signing algorithm for CDNI, there’s no reason IMO why we can’t start with a single Hash function & Digital Signature Algorithm for baseline interoperability and if folks need something else in future they can specify it.

Several CDNs support >1 HF/DSA because things have evolved over time, some newer functions are considered more secure or whatever and backwards compatibility needs to be maintained.

We’re not in that position, the document is describing a new signing mechanism that everyone will need to implement, we have no backwards compatibility to maintain so let’s not carry any historical baggage resulting from CDN-proprietary URI signing schemes along with us.

Ben

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 13 May 2014 07:58:26 +0000

All,

> which, even though it passes URI signing validation, is a different URI/resource to the one that was originally signed.

That seems like a valid concern is some situations. At teh same time, I believe there are valid situations where the CSP wants to allow un-signed query strings (because they can only affect things that need not be authorised). So how about adding one piece of metadata to CDNI Metadata that says:
	* allow query string to be extended after signature, which means (using the above example):
		- if the signature protecting "http://videos.example/videos?title=batman” is valid, then authorize "http://videos.example/videos?title=batman&<URI Signing stuff>&quality=HD” 
		- if the signature protecting "http://videos.example/videos?title=batman” is NOT valid, then block "http://videos.example/videos?title=batman&<URI Signing stuff>&quality=HD” 
	* disallow query string to be extended after signature, which means (using the above example):
		- regardless of URI signature validity, block "http://videos.example/videos?title=batman&<URI Signing stuff>&quality=HD” 

> The attack surface could be larger than leaked keys. E.g. if the 5 keys the uCDN says are allowed came from different content providers, then the key does’t have to leak anywhere, an enterprising i…

In that situation, the uCDN woudl not advertise the 5 key IDs for all contents. It would only advertise key-ID 1 for CSP1. So an individual knowing CSP1’s key woudl not be able to access CSP2 content. 

> - Within CDNI Metadata the URI signing keys are associated with the content to which they apply.

I believe that is already the case:
" o  Allowable Key ID set that the Signed URI's Key ID information
      element can reference
"

> - The CDNI Metadata can contain >1 key for a given piece of content.

I believe that is already the case (what is signaled is Key ID and not the key itself of course):
" o  Allowable Key ID set that the Signed URI's Key ID information
      element can reference
"

> - If any of the keys included in the relevant CDNI Metadata correctly validate the URI, then it is valid.

I believe this is effectively already teh case. The difference is that the key-ID can optionally be included in the URI, so that the CDN does not need to successively try ecah and every Key from the set of authorized keys for that content.

> That way a CSP can provide/use multiple keys if they want, there is no need to signal the keyID to be used in the URI itself (so absolutely no ability for a User Agent to affect it in any way), and…

I don’t see that includeing the key-ID in the URI increases the security risk in any ways (since the set of allowed key-ID is conveyed in metadata always). And it has a benefit in avoiding to systematically have to try with every possible key.
Am I missing something?

> We’re not in that position, the document is describing a new signing mechanism that everyone will need to implement, we have no backwards compatibility to maintain so let’s not carry any historical…

That sounds right to me.

Francois

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Thu, 15 May 2014 07:05:43 +0000

Hi Ben, Francois,

> From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
> Sent: dinsdag 13 mei 2014 9:58
> To: Niven-Jenkins Ben
> Cc: Francois Le Faucheur (flefauch); Brandenburg, R. (Ray) van;
> [email-masked]; Kent Leung (kleung)
> >>> 1) In section 2 the draft says "Any attributes appended in such way
> >>> after the URI Signature has been calculated are not validated for
> >>> the purpose of content access authorization."
> >>>
> >>> If additional query parameters can be appended to the URI which are
> >>> not validated, could a UA obtain content that it isn't authorised to
> >>> obtain by adding additional query parameters? It seems like
> >>> something that could be worth discussing in the security considerations
> section?
> >>>
> >>
> >> I'm not sure I understand you correctly. Any parameters added by the UA
> after the URI Signature are not taken into account during the signing process.
> As such, there is no way for these parameters to affect the outcome of the
> validation process. The only way for the UA to affect the validation outcome
> would be to change the IR Signing Package Attribute, however, this would
> cause the signature to be invalid.
> >
> >
> > Section 3 of the draft states "The entire URI except the "scheme name"
> part is protected by the URI signature." But if someone can append
> additional query parameters to a signed URI and still have it be considered
> "correctly signed" by a dCDN then the proposed mechanism is not protecting
> "the entire URI".
> >
> > which, even though it passes URI signing validation, is a different
> URI/resource to the one that was originally signed.
> 
> 
> That seems like a valid concern is some situations. At teh same time, I believe
> there are valid situations where the CSP wants to allow un-signed query
> strings (because they can only affect things that need not be authorised). So
> how about adding one piece of metadata to CDNI Metadata that says:
> 		- if the signature protecting
> "http://videos.example/videos?title=batman" is valid, then authorize
> "http://videos.example/videos?title=batman&<URI Signing
> stuff>&quality=HD"
> 		- if the signature protecting
> "http://videos.example/videos?title=batman" is NOT valid, then block
> "http://videos.example/videos?title=batman&<URI Signing
> stuff>&quality=HD"
> 		- regardless of URI signature validity, block
> "http://videos.example/videos?title=batman&<URI Signing
> stuff>&quality=HD"
> 

I see Ben's point. That said, such behavior would be easily detectable at the dCDN. The dCDN knows that any parameters in the query string to the right of the URI Signing Attribute have been added by the UA instead of the uCDN. It would be fairly easy for a dCDN to ignore any such parameters for the purposes of selecting a content item (e.g. only using it for purposes of logging). I agree that we need to explicitly point out this potential vulnerability in the draft, and maybe even add some recommendations for the dCDN. Francois' proposal of adding an extra metadata field could indeed add some further flexibility to such behavior, although I don't think it's strictly necessary.

> >
> >
> >>> 2) Section 2.2 allows the KeyID to be included in the Signed URI.
> >>> This also seems like it might open a security hole as a malicious UA
> >>> could strip the original URISigningPackage attribute, sign the URI
> >>> with a Key under its control (possibly altering other things like
> >>> the actual URI or expiry time) and include the appropriate KeyID for that
> new Key in the new URISigningPackage.
> >>>
> >> The use case for signaling the KeyID is the uCDN allowing multiple keys to
> be used in the metadata. In order to signal the used Key to the dCDN, the
> KeyID field is used.
> >>
> >> Let's assume that for a given content item, the uCDN allows five different
> keys to be used (as announced in the metadata). You're right that if the UA
> would somehow have access to one of these five keys, and the associated
> keyID, it could recalculate the URISigningPackage attribute. However, I don't
> think this problem stems from the use of the KeyID field. Even if there would
> be only one key, and this key would be leaked, then the UA could also resign
> the UA. So the question is, is the chance of a given key leaking bigger if it is
> part of a set of allowed keys instead of the only allowed key?
> >
> > The attack surface could be larger than leaked keys. E.g. if the 5 keys the
> uCDN says are allowed came from different content providers, then the key
> does't have to leak anywhere, an enterprising individual with legitimate
> knowledge of  CSP1's key could use CSP1's key to sign URIs and get hold of
> content from CSP2.
> 
> In that situation, the uCDN woudl not advertise the 5 key IDs for all contents.
> It would only advertise key-ID 1 for CSP1. So an individual knowing CSP1's key
> woudl not be able to access CSP2 content.
> 
> >
> > For the use case presented I think there is a better/easier way to solve it
> rather than have each UA->dCDN request include which key to use.
> >
> > What I'd propose is:
> I believe this is effectively already teh case. The difference is that the key-ID
> can optionally be included in the URI, so that the CDN does not need to
> successively try ecah and every Key from the set of authorized keys for that
> content.
> 
> >
> > That way a CSP can provide/use multiple keys if they want, there is no
> need to signal the keyID to be used in the URI itself (so absolutely no ability
> for a User Agent to affect it in any way), and you can do key-rollover without
> having to co-ordinate KeyIDs between the party responsible for signing the
> URI (the uCDN/CSP probably) and the party responsible for validating them
> (the dCDN).
> 
> I don't see that includeing the key-ID in the URI increases the security risk in
> any ways (since the set of allowed key-ID is conveyed in metadata always).
> And it has a benefit in avoiding to systematically have to try with every
> possible key.
> Am I missing something?
> 

Agree with Francois. As long as the CDNI Metadata Interface can be used to convey the set of allowed keys per uCDN/dCDN combination, I don't see a risk. 

> >
> >
> >>> 3) Regarding hash functions & digital signature algorithms, the
> >>> draft hints at allowing several options for each and defines a
> >>> default in case a particular algorithm is not specified in the
> URISigningPackage.
> >>>
> >>> This seems a bit overkill to me. To aid inter-operability, I think
> >>> it would be better to specify a single algorithm for each unless
> >>> there are use cases for requiring support for more than one
> >>> algorithm in the first version defined in the draft?
> >>>
> >>
> >> Are you saying you would prefer to keep the HF and DSA fields but only
> define one possible value for them in this document, or are you saying you
> would prefer to remove these fields and just specify a single mandatory hash
> function and DS algorithm? Personally, I think it is useful to have the option
> of signaling different hash functions or DS algorithms.
> >
> > I don't like the idea of specifying >1 hash function/digital signature
> algorithm in this document.
> >
> > This document is defining a new URI signing algorithm for CDNI, there's no
> reason IMO why we can't start with a single Hash function & Digital Signature
> Algorithm for baseline interoperability and if folks need something else in
> future they can specify it.
> >
> > Several CDNs support >1 HF/DSA because things have evolved over time,
> some newer functions are considered more secure or whatever and
> backwards compatibility needs to be maintained.
> >
> > We're not in that position, the document is describing a new signing
> mechanism that everyone will need to implement, we have no backwards
> compatibility to maintain so let's not carry any historical baggage resulting
> from CDN-proprietary URI signing schemes along with us.
> 
> That sounds right to me.

Agree. 

> >>> of this draft
> >>> (http://tools.ietf.org/html/draft-leung-cdni-uri-signing-05) is
> >>> substantial for us to adopt it as a working group item.  However,
> >>> Francois and I did not feel comfortable conducting a "Hum," since
> >>> there were not a lot of people present who had read the draft.  This
> draft was proposed in response to the following charter item:
> >>>>
> >>>> A specification for "CDNI URI Signing". This document will specify
> >>>> a mechanism that allows interconnected CDNs to support access
> >>>> control by signing content URIs. This may involve extensions to the
> >>>> CDNI interfaces (e.g. CDNI Metadata interface, CDNI Logging interface).
> >>>>
> >>> for this draft to be accepted as a working group item, which will
> >>> occur on March 21st.  If anyone has any major concerns with this,
> >>> please post comments and concerns to the list.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Daryl & Francois
> >>>>
> >>>>
> >>>>
> >> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u
> niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden,
> wordt u verzocht dat aan de afzender te melden en het bericht te
> verwijderen. TNO aanvaardt geen aansprakelijkheid voor de inhoud van
> deze e-mail, de wijze waarop u deze gebruikt en voor schade, van welke
> aard ook, die verband houdt met risico's verbonden aan het elektronisch
> verzenden van berichten.
> >>
> >>
> >>
> >> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you are
> requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use it and
> for damage of any kind resulting from the risks inherent to the electronic
> transmission of messages.
> >

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 15 May 2014 07:38:30 +0000

Hi Ray,

On 15 May 2014, at 09:05, Brandenburg, R. (Ray) van <[email-masked]> wrote:
> I see Ben's point. That said, such behavior would be easily detectable at the dCDN. The dCDN knows that any parameters in the query string to the right of the URI Signing Attribute have been added by the UA instead of the uCDN. It would be fairly easy for a dCDN to ignore any such parameters for the purposes of selecting a content item

The CDNI-Metadata interface includes an “ignore-query-string” that controls when the query-string is to be taken into account and when its not to be taken into account for caching. So we cannot assume that the dCDN would just always ignore query strings for content selection in the cache.

"
Property: ignore-query-string

         Description: Allows a cache to ignore URI query string
         parameters while comparing URIs for equivalence.  Each query
         parameter to ignore is specified in the list.  If all query
         parameters should be ignored, then the list MUST be empty.
“

Francois

> (e.g. only using it for purposes of logging). I agree that we need to explicitly point out this potential vulnerability in the draft, and maybe even add some recommendations for the dCDN. Francois' proposal of adding an extra metadata field could indeed add some further flexibility to such behavior, although I don't think it's strictly necessary.

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Thu, 15 May 2014 07:55:44 +0000

Hi Francois,

> Sent: donderdag 15 mei 2014 9:39
> To: Brandenburg, R. (Ray) van
> Cc: Francois Le Faucheur (flefauch); Niven-Jenkins Ben; [email-masked]; Kent
> Leung (kleung)
> >> additional query parameters to a signed URI and still have it be
> >> considered "correctly signed" by a dCDN then the proposed mechanism
> >> is not protecting "the entire URI".
> >>>
> >>> That aside, as it stands, as specified in the draft I believe it is
> >>> possible to do
> >> the following:
> >>>
> >>> Take a URI, e.g.
> >> That seems like a valid concern is some situations. At teh same time,
> >> I believe there are valid situations where the CSP wants to allow
> >> un-signed query strings (because they can only affect things that
> >> need not be authorised). So how about adding one piece of metadata to
> CDNI Metadata that says:
> > I see Ben's point. That said, such behavior would be easily detectable
> > at the dCDN. The dCDN knows that any parameters in the query string to
> > the right of the URI Signing Attribute have been added by the UA
> > instead of the uCDN. It would be fairly easy for a dCDN to ignore any
> > such parameters for the purposes of selecting a content item
> 
> The CDNI-Metadata interface includes an "ignore-query-string" that controls
> when the query-string is to be taken into account and when its not to be
> taken into account for caching. So we cannot assume that the dCDN would
> just always ignore query strings for content selection in the cache.
> 

I'm not suggesting that the dCDN ignore all query strings. I'm suggesting that it ignores any query strings that are to the right of the URI Signing Attribute. Are you saying that any such text in the URI Signing draft might conflict with text in the Metadata draft? In that case, we might need to fix this in both drafts. 

Ray

> > (e.g. only using it for purposes of logging). I agree that we need to explicitly
> point out this potential vulnerability in the draft, and maybe even add some
> recommendations for the dCDN. Francois' proposal of adding an extra
> metadata field could indeed add some further flexibility to such behavior,
> although I don't think it's strictly necessary.
> 
> 
>

---

From: Kevin Ma J <[email-masked]>
Date: Thu, 15 May 2014 08:36:22 +0000

Hi all,

  Does the signing token not contain all of the attributes (including non-CDNI attributes) of the signed query string (note: there is a known size concern with this approach)?  The dCDN should probably only rely on those in the token, if it is concerned about tampering?

--  Kevin J. Ma

Sent from my iPhone

> On May 15, 2014, at 8:55 AM, "Brandenburg, R. (Ray) van" <[email-masked]> wrote:
> 
> Hi Francois,
>

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Mon, 19 May 2014 08:30:57 +0000

Correct. I will add such a note to the next iteration.

Thanks,

Ray

On 15/05/14 10:36, "Kevin Ma J" <[email-masked]> wrote:

>Hi all,
>
>  Does the signing token not contain all of the attributes (including
>non-CDNI attributes) of the signed query string (note: there is a known
>size concern with this approach)?  The dCDN should probably only rely on
>those in the token, if it is concerned about tampering?
>
>--  Kevin J. Ma
>
>Sent from my iPhone
>
>>>>>    * disallow query string to be extended after signature, which
>>>>>means
>>>>> (using the above example):
>> I'm not suggesting that the dCDN ignore all query strings. I'm
>>suggesting that it ignores any query strings that are to the right of
>>the URI Signing Attribute. Are you saying that any such text in the URI
>>Signing draft might conflict with text in the Metadata draft? In that
>>case, we might need to fix this in both drafts.
>> 
>> Ray
>> 
>>> "
>> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien
>>u niet de geadresseerde bent of dit bericht abusievelijk aan u is
>>toegezonden, wordt u verzocht dat aan de afzender te melden en het
>>bericht te verwijderen. TNO aanvaardt geen aansprakelijkheid voor de
>>inhoud van deze e-mail, de wijze waarop u deze gebruikt en voor schade,
>>van welke aard ook, die verband houdt met risico's verbonden aan het
>>elektronisch verzenden van berichten.
>> 
>> 
>> 
>> This message may contain information that is not intended for you. If
>>you are not the addressee or if this message was sent to you by mistake,
>>you are requested to inform the sender and delete the message. TNO
>>accepts no liability for the content of this e-mail, for the manner in
>>which you use it and for damage of any kind resulting from the risks
>>inherent to the electronic transmission of messages.
>>