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

From: Thomson, Martin ^lt;Martin.Thomson@andrew.com>
Date: Tue Feb 06 2007 - 22:38:25 EST

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:Martin.Thomson@andrew.com]
> Sent: Wednesday, 7 February 2007 2:10 PM
> To: geopriv@ietf.org
> Cc: Henning Schulzrinne
> Subject: [Geopriv] l7-lcp-ps: Signatures issue
>
> 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]
------------------------------------------------------------------------------------------------
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
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue, 6 Feb 2007 21:38:25 -0600

This archive was generated by hypermail 2.1.8 : Tue Feb 06 2007 - 22:38:07 EST