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

From: Dawson, Martin ^lt;Martin.Dawson@andrew.com>
Date: Wed Feb 14 2007 - 01:11:36 EST

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
Received on Wed, 14 Feb 2007 00:11:36 -0600

This archive was generated by hypermail 2.1.8 : Wed Feb 14 2007 - 01:11:13 EST