RE: [Geopriv] WGLC on draft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)

From: jerome.grenier@bell.ca
Date: Wed Feb 14 2007 - 14:00:59 EST

I agree with Brian and Martin. As an emergency services provider, we need a way to do the following things, in order of priority (which may also happen to roughly be in order of feasibility) :

1. prevent a caller to forge his location information from scratch
2. prevent a caller to reuse one of his old valid location
3. prevent a caller to use the currently valid location of someone else (done either by explicit relationship or by network sniffing)
4. prevent an attacker to modify the location of a legitimate caller

We're definitely after prank callers... and the more we catch the better !

I think the need for digital signatures has become apparent, even though the yet-to-be-defined mechanism might not cover the full threat spectrum. In that perspective, the following extract from draft-ietf-geopriv-l7-lcp-ps-00 should be re-addressed :

        10.3. Requirements
        
           The following requirements are placed on the location-by-value
           approach:
        
           o No conclusion was reached whether a PIDF-LO or just location
              information has to be signed.
        
           o No conclusion was reached whether location information should be
              signed.
        
           o No conclusion was reached what could be signed.

Regards,

Jérôme

-----Message d'origine-----
De : Dawson, Martin [mailto:Martin.Dawson@andrew.com]
Envoyé : 14 février 2007 01:12
À : Brian Rosen; Henning Schulzrinne
Cc : geopriv@ietf.org
Objet : RE: [Geopriv] WGLC on draft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)

I certainly don't mind which solution is used. The NENA requirement for "location dependability" includes elements of authentication and integrity.

The required characteristics are:
1. Mechanism to identify the source of the location is available
2. Mechanism to detect tampering post-source is available
3. Mechanism to determine the time at which the location information was acquired.
4. Mechanism to distinguish the location object provided by one apparent caller from that of another apparent caller is available.

The Thomson draft was written with these goals in mind. If we can discuss, modify, extend, select from the available specification options that would be fine.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, 14 February 2007 1:04 PM
To: Dawson, Martin; 'Henning Schulzrinne'
Cc: geopriv@ietf.org
Subject: RE: [Geopriv] WGLC on draft-ietf-geopriv-l7-lcp-ps-00 (PIDF-LOdigitalsignatures)

I believe there are solutions which allow a digital signature to be used
with all of the relevant protocols, albeit with some extension to existing
specifications. I think that would be preferable to a solution that only
worked with some of them. The key to doing this is to recognize that even
those protocols that do not use precisely a PIDF LO can have the information
they carry mapped to the fields of a PIDF LO. We therefore would define a
construction rule for each of the protocols which would yield the same
string in any of the protocols for the same location, compute the hash of
that string and a time stamp, sign that. Then, no matter what protocol was
used subsequently, a recipient could apply the appropriate rule for the
protocol it used, create the same string, and verify the signature.

The extension would be to specify the rule, and to provide the fields to
pass the signature (and time stamp if needed).

Brian

> -----Original Message-----
> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> Sent: Tuesday, February 13, 2007 6:48 PM
> To: Brian Rosen; Henning Schulzrinne
> Cc: geopriv@ietf.org
> Subject: RE: [Geopriv] WGLC on draft-ietf-geopriv-l7-lcp-ps-00 (PIDF-
> LOdigitalsignatures)
>
> I agree with Brian's assessment here - largely it's about being able to
> eliminate the ability to routinely *and without exploit* misrepresent your
> location. Although Henning does highlight how the use of signatures does
> raise the bar as far as how geographically targeted the exploit has to be.
>
> I cannot agree that the lack of support of this by "non-L7" protocols
> obviates the ability to have the requirement. It feels like arguing that
> the legacy must always limit the possible. Certainly the NENA requirements
> for the acquisition protocol include the ability to do the things that the
> below-referenced draft mention (that's pretty much the main reason the
> draft was written).
>
> Cheers,
> Martin
>
> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Wednesday, 14 February 2007 8:41 AM
> To: 'Henning Schulzrinne'
> Cc: geopriv@ietf.org
> Subject: RE: [Geopriv] WGLC on draft-ietf-geopriv-l7-lcp-ps-00 (PIDF-
> LOdigitalsignatures)
>
> The threat is the first one. Script kiddie writes a script that gets a
> call
> to 9-1-1 that looks like it comes from somewhere else, resources are
> diverted to that location. You may not consider the problem interesting,
> but everyone in the 9-1-1 system I know does.
>
> The second attack is also interesting, but is not the one I think
> signatures
> help with. The location reported IS the location of the caller. The
> caller
> itself is bad.
>
> Brian
>
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > Sent: Tuesday, February 13, 2007 4:26 PM
> > To: Brian Rosen
> > Cc: jerome.grenier@bell.ca; geopriv@ietf.org
> > Subject: Re: [Geopriv] WGLC on draft-ietf-geopriv-l7-lcp-ps-00 (PIDF-
> > LOdigital signatures)
> >
> > One of the problems of this discussion is that the threat models are
> > never quite explained. There are at least two that are of interest
> > related to signing:
> >
> > (1) Human users trying to pretend to be elsewhere. ("Alice, in NYC,
> > calls the SF fire department, by swapping signed locations with
> > Bob.") I don't consider this attack terribly interesting, due to the
> > difficulty of making it scale beyond individual crank calls.
> >
> > (2) Bots; they can get the real signature for their real location.
> > The advantage of signing is that the bot has to be located in the
> > PSAP service area, so that this limits the size of the bot army an
> > attacker can bring to bear.
> >
> > We can now just replay the usual discussion again about the
> > difficulty of actually creating verifiable signatures, unless
> > extremely restrictive assumptions are made on who can operate a LIS.
> > The owners of such verifiable signatures can be prioritized, however.
> >
> > Henning
> >
> > On Feb 13, 2007, at 3:48 PM, Brian Rosen wrote:
> >
> > > I am a proponent of signing location. I think it provides a
> > > worthwhile
> > > level of protection against wholesale forgery of location, but does
> > > not
> > > prevent some forms of replay attacks (or stealing a valid location
> > > from a
> > > compromised or cooperating device, and representing that as the
> > > location
> > > when it isn't).
> > >
> > > However, I believe that the signature mechanism must pass through ALL
> > > location configuration and conveyance protocols, which would include
> > > LLDP-MED and DHCP (and, depending on how things work out, SUPL).
> > > The cited
> > > work does not do that.
> > >
> > > I also wonder if the extra work involved in passing identity
> > > actually helps.
> > > I think forging the identity is as easy as forging the location,
> > > and if you
> > > compromise an element, or have an accomplice, then you can
> > > masquerade as
> > > another identity. Some identities can be verified, others cannot.
> > > Couple
> > > that with the necessity that identity not always be revealed when
> > > location
> > > is revealed, and you have to question the value of that part of it.
> > >
> > > I think a signature by the location source, with a time stamp,
> > > provides
> > > substantial protection. We can make it better, but at what cost,
> > > and with
> > > what additional complexity, and with what value.
> > >
> > > I do think we should first decide if the threat (trivial forgery) is
> > > significant to do something about it. I think it is.
> > >
> > > Brian
> > >
> > >
> > >> -----Original Message-----
> > >> From: jerome.grenier@bell.ca [mailto:jerome.grenier@bell.ca]
> > >> Sent: Tuesday, February 13, 2007 3:34 PM
> > >> To: geopriv@ietf.org
> > >> Subject: RE: [Geopriv] WGLC on draft-ietf-geopriv-l7-lcp-ps-00 (PIDF-
> > >> LOdigital signatures)
> > >>
> > >> It seems to me that many non-working group documents of Geopriv
> > >> have the
> > >> potential for a promotion, especially the ones that have been sitting
> > >> there for months. With official milestones in the range of early
> > >> 2005, I
> > >> wonder what the criteria for promoting them to active working group
> > >> documents are. From my perspective, many core issues inherent to the
> > >> Geopriv charter are not yet formally addressed through working group
> > >> documents.
> > >>
> > >> Here is an example I came across, based on a need we had as an
> > >> emergency
> > >> service provider, to find a standard way to validate the integrity of
> > >> provided location data, in order to prevent location forgery. From
> > >> draft-
> > >> ietf-geopriv-l7-lcp-ps-00, the need for digital signatures for
> > >> PIDF-LO
> > >> documents is clearly acknowledged, with many surrounding issues and
> > >> counter-measures presented, but a specific signing technique is
> > >> stated to
> > >> be out-of-scope of the document. In this context, I find quite
> > >> relevant to
> > >> promote draft-thomson-domain-auth-01 to a working group document
> > >> as it
> > >> defines a way to perform such signatures using already established
> > >> standards.
> > >>
> > >> Regards,
> > >>
> > >> Jérôme
> > >>
> > >> -----Message d'origine-----
> > >> De : Andrew Newton [mailto:andy@hxr.us]
> > >> Envoyé : 5 février 2007 23:08
> > >> À : GEOPRIV WG
> > >> Objet : [Geopriv] WGLC on draft-ietf-geopriv-l7-lcp-ps-00
> > >>
> > >> All,
> > >>
> > >> This message marks the issuance of a working group last call (WGLC)
> > >> on GEOPRIV's Internet Draft entitled "GEOPRIV Layer 7 Location
> > >> Configuration Protocol; Problem Statement and Requirements" (draft-
> > >> ietf-geopriv-l7-lcp-ps-00.txt). You may view this document at
> > >> http://
> > >> www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-00.txt.
> > >>
> > >> Please post comments and questions to this mailing list no later than
> > >> 20 February 2007.
> > >>
> > >> -andy, GEOPRIV co-chair
> > >>
> > >> _______________________________________________
> > >> 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
> > >
> > >
> > > _______________________________________________
> > > 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
>
> --------------------------------------------------------------------------
> ----------------------
> 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, 14 Feb 2007 14:00:59 -0500

This archive was generated by hypermail 2.1.8 : Wed Feb 14 2007 - 14:00:49 EST