Subject: [Geopriv] l7-lcp-ps: Signatures issue

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 6 Feb 2007 21:09:53 -0600

I have an issue to raise about draft-ietf-geopriv-l7-lcp-ps-00 (and a small nit).

It's a convoluted topic; I hope my explanation is adequate.

1: http://tools.ietf.org/html/draft-ietf-geopriv-l7-lcp-ps-00#section-8.2.1

Section 8.2.1 of the l7-lcp-ps proposes a technique for applying two digital signatures to protect against theft and replay.

In summary, the technique relies on a signature from the LIS to prevent tampering and to identify the source of the information.  The signed information includes a non-spoofable (unspoofable?) identifier that is provided by the Target.

	Signed-LO = Sig(IDlis, { LO, NSID, ... })

where:
	Sig = signing; 
	LO = location object;
	IDlis is the identity of the LIS; 
	IDtgt is the identity of the Target;
	NSID = non-spoofable ID based on IDtgt, e.g. = hash(IDtgt)

The Target then signs the received object, including the LIS signature.

	Double-Signed-LO = Sig(IDtgt, Sig(IDlis, { LO, NSID, ... }))

The signature applied by the Target uses the same identifier as the one from which the non-spoofable ID is derived.  From this a recipient can validate signatures to determine the following facts:

 - That the LIS generated the LO. (provided by Sig(IDlis))
 - That the LIS generated the LO for the Target. (Sig(IDlis))
 - That the Target received the LO. (Sig(IDtgt))

This still does not prove that the Target was actually at the given location:  Attacker A is in NY, Attacker B is in Sydney.  Attacker B requests a LO using Attacker A's NSID.  Attacker A can pretend to be in Sydney with the support of a digital signature - without requiring the sharing of credentials.

If a location recipient receives a doubly-signed LO in this fashion, in the absence of other information, this is still not sufficient.  The signed LO can still be replayed, providing that it is stolen after the Target applies the signature.  It still needs to authenticate the Target in order to prove* that the location actually applies to the entity that it is talking to.

The only applicable solution to this problem is to require that the location recipient authenticate the entity that provides location.  If that entity can be authenticated, and the identifier they use (or something derived from it that is non-spoofable, like a hash) is in the signed LO, the location can be said to be attributed to them.  By authenticating on the conveyance channel, the Target implies signature of the included LO.  That is, they MUST have received the LO because they are the one that is sending it.

The benefit that signing provides - the need for an attacker to have presence at the location, either personally or through a willing associate - is not appreciably improved by adding a second signature.  Nor does the second signature allow theft to be detected, except if authentication is used.

2: http://tools.ietf.org/html/draft-ietf-geopriv-l7-lcp-ps-00#section-10.2

Currently, I only have one other comment and that is that the countermeasure entitled "Asserted Location", shown in Section 10.2, Table 1, is not defined anywhere in the document.  (And, if it is what I think it is, I'm not sure how it can prevent place shifting without other measures in place - some justification for the X placement in this table might be beneficial).

Cheers,
Martin 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 6 Feb 2007 21:38:25 -0600

I just realized a mistake in my original mail; the second signature is intended to also act as authentication:

	Double-Signed-LO = Sig(IDtgt, { channel parameters, 
                                      Sig(IDlis, { LO, NSID, ... }) })

However, unless the channel parameter include IDtgt, this suffers from the same problem.  If, for example, a public key is used (it need not be hashed), the public key has to be linked to some identity that is meaningful to the location recipient (i.e. the From address).

An attack is still possible if Attacker A gets Attacker B to obtain location using Attacker A's NSID.  To take the SIP case, Attacker A can also happily pretend to be anyone they choose in the From: header of the request if there is no correlation between the From: header contents and the public key used to apply the signature.

Cheers,
Martin

> -----Original Message-----
> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Wednesday, 7 February 2007 2:10 PM
> To: [email-masked]
> Cc: Henning Schulzrinne
> Subject: [Geopriv] l7-lcp-ps: Signatures issue
> 
> Section 8.2.1 of the l7-lcp-ps proposes a technique for applying two
> digital signatures to protect against theft and replay.
> 
> In summary, the technique relies on a signature from the LIS to prevent
> tampering and to identify the source of the information.  The signed
> information includes a non-spoofable (unspoofable?) identifier that is
> provided by the Target.
> 
> The signature applied by the Target uses the same identifier as the one
> from which the non-spoofable ID is derived.  From this a recipient can
> validate signatures to determine the following facts:
> 
> This still does not prove that the Target was actually at the given
> location:  Attacker A is in NY, Attacker B is in Sydney.  Attacker B
> requests a LO using Attacker A's NSID.  Attacker A can pretend to be in
> Sydney with the support of a digital signature - without requiring the
> sharing of credentials.
> 
> If a location recipient receives a doubly-signed LO in this fashion, in
> the absence of other information, this is still not sufficient.  The
> signed LO can still be replayed, providing that it is stolen after the
> Target applies the signature.  It still needs to authenticate the Target
> in order to prove* that the location actually applies to the entity that
> it is talking to.
> 
> The only applicable solution to this problem is to require that the
> location recipient authenticate the entity that provides location.  If
> that entity can be authenticated, and the identifier they use (or
> something derived from it that is non-spoofable, like a hash) is in the
> signed LO, the location can be said to be attributed to them.  By
> authenticating on the conveyance channel, the Target implies signature of
> the included LO.  That is, they MUST have received the LO because they are
> the one that is sending it.
> 
> The benefit that signing provides - the need for an attacker to have
> presence at the location, either personally or through a willing associate
> - is not appreciably improved by adding a second signature.  Nor does the
> second signature allow theft to be detected, except if authentication is
> used.
> 
> Currently, I only have one other comment and that is that the
> countermeasure entitled "Asserted Location", shown in Section 10.2, Table
> 1, is not defined anywhere in the document.  (And, if it is what I think
> it is, I'm not sure how it can prevent place shifting without other
> measures in place - some justification for the X placement in this table
> might be beneficial).
> 
> Cheers,
> Martin
>

---

From: Andrew Newton <[email-masked]>
Date: Wed, 7 Feb 2007 11:01:41 -0500

<warning caffeine_level="low" nonsense_spouting_factor="high" />

Martin,

I'm having a hard time following this, but I think part of your  
premise is that there is not identity in the signature, therefore  
replay is trivial.  However, an LO can contain an identity.

I do believe we have a problem if no time value is signed.  An  
attacker can go get signed LO's and then replay them at another time  
and place.

-andy

On Feb 6, 2007, at 10:38 PM, Thomson, Martin wrote:

> I just realized a mistake in my original mail; the second signature  
> is intended to also act as authentication:
>
> However, unless the channel parameter include IDtgt, this suffers  
> from the same problem.  If, for example, a public key is used (it  
> need not be hashed), the public key has to be linked to some  
> identity that is meaningful to the location recipient (i.e. the  
> From address).
>
> An attack is still possible if Attacker A gets Attacker B to obtain  
> location using Attacker A's NSID.  To take the SIP case, Attacker A  
> can also happily pretend to be anyone they choose in the From:  
> header of the request if there is no correlation between the From:  
> header contents and the public key used to apply the signature.
>
> Cheers,
> Martin
>
>> 1: http://tools.ietf.org/html/draft-ietf-geopriv-l7-lcp- 
>> ps-00#section-
>> 8.2.1
>>
>> --------------------------------------------------------------------- 
>> -----
>> ----------------------
>> --------------------------------------------------------------------- 
>> -----
>> ----------------------
>> [mf2]

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 7 Feb 2007 15:45:40 -0600

My apologies for the complexity, but I'm having a hard time reconciling it in my head, let alone being able to put something coherent in writing.

The whole reason for the keyID concept was to avoid including identity in the LO and thereby revealing this information to the LIS.

The problem is independent of whether time is included.  I purposefully left out values like validity times from the discussion to concentrate on the core issue.  The "..." in the expression implies that other elements are signed, like time.

Cheers,
Martin

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Thursday, 8 February 2007 3:02 AM
> To: Thomson, Martin
> Cc: [email-masked]; Henning Schulzrinne
> Subject: Re: [Geopriv] l7-lcp-ps: Signatures issue
>