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

From: Thomson, Martin ^lt;Martin.Thomson@andrew.com>
Date: Wed Feb 07 2007 - 16:45:40 EST

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


> -----Original Message-----
> From: Andrew Newton [mailto:andy@hxr.us]
> Sent: Thursday, 8 February 2007 3:02 AM
> To: Thomson, Martin
> Cc: geopriv@ietf.org; Henning Schulzrinne
> Subject: Re: [Geopriv] l7-lcp-ps: Signatures issue
>
> <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
>

------------------------------------------------------------------------------------------------
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 Wed, 7 Feb 2007 15:45:40 -0600

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