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

From: Andrew Newton ^lt;andy@hxr.us>
Date: Wed Feb 07 2007 - 11:01:41 EST

<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:
>
> 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

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Wed, 7 Feb 2007 11:01:41 -0500

This archive was generated by hypermail 2.1.8 : Wed Feb 07 2007 - 11:01:45 EST