[Geopriv] l7-lcp-ps: Signatures issue

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

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
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue, 6 Feb 2007 21:09:53 -0600

This archive was generated by hypermail 2.1.8 : Tue Feb 06 2007 - 22:09:41 EST