RE: E911 and appliances

Write that down in the security considerations section.
This group needs to be focused on location. The users
of the object need to deal with user identity, and they
have to deal with the whole problem.

Brian

> -----Original Message-----
> From: Adam Shostack [mailto:adam@zeroknowledge.com]
> Sent: Monday, August 20, 2001 2:39 PM
> To: Rosen, Brian
> Cc: 'Christopher Sipes'; andrew@daviel.org;
> geopriv@mail.apps.ietf.org;
> hgs@cs.columbia.edu
> Subject: Re: E911 and appliances
>
>
> If you don't include user information in the location information,
> then you create an ugly set of cross-protocol privacy attacks, where I
> freely reveal my "anonymised" location, and then reveal my phone
> number, and it turns out the same cookie is attached to both.
>
> Adam
>
>
> On Mon, Aug 20, 2001 at 02:30:03PM -0400, Rosen, Brian wrote:
> > Wouldn't you say that user identity information is NOT in
> the domain
> > of geopriv, and should be explicitly declared out of scope for
> > inclusion in the object itself? You might have to provide
> > user information to authenticate entities, but that is
> > ancilliary to providing it in the location object.
> >
> > Brian
> >
> > -----Original Message-----
> > From: Christopher Sipes [mailto:CSipes@Forrester.com]
> > Sent: Monday, August 20, 2001 2:26 PM
> > To: Adam Shostack
> > Cc: andrew@daviel.org; geopriv@mail.apps.ietf.org;
> hgs@cs.columbia.edu
> > Subject: Re: E911 and appliances
> >
> >
> >
> > Perhaps, in answer to the question regarding one's
> anonimity, while still
> > being able to provide geographical location information, that the
> > implementation by default of this tool provides only the
> caller's three
> > dimensional location. Then, as an increased security
> measure, in areas
> > where it may be necessary, the option of providing
> caller/user information
> > will then be appended to the data packet. My thinking is,
> that, there
> > should be some implied consent/responsibility when dialing
> an emergency
> > number, though not so many standards such that individuals
> may be detered
> > from reporting a situation. If necessary, we simply limit
> the information
> > provided to what might be most important, being specific
> location of the
> > call.
> >
> >
> > || Chris Sipes | Web Developer | Forrester Research, Inc. | 400
> > Technology Square | Cambridge, MA 02139 | email:
> csipes@forrester.com |
> > 617.613.6009 ||
> >
> >
> > Adam Shostack <adam@zeroknowledge.com>
> > 08/20/2001 01:39 PM
> >
> > To: Henning Schulzrinne <hgs@cs.columbia.edu>
> > cc: Andrew Daviel <andrew@daviel.org>,
> > geopriv@mail.apps.ietf.org
> > Subject: Re: E911 and appliances
> >
> >
> >
> > On Fri, Aug 17, 2001 at 01:23:56PM -0700, Henning Schulzrinne wrote:
> > >
> > >
> > > Adam Shostack wrote:
> > > >
> > > > On Fri, Aug 17, 2001 at 11:47:42AM -0700, Henning
> Schulzrinne wrote:
> > > > > In terms of the discussion here, I suspect that we'll
> see more choices
> > > > > as to how locations are being reported. However,
> given that people
> > > > > dialing 911 are often not exactly in the clearest
> state of mind, I
> > have
> > > > > a hard time picturing a device that requires a user
> to make detailed
> > > > > choices in a scroll-down menu as to the location
> accuracy while the
> > > > > house is on fire.
> > > >
> > > > In terms of interface, I would see as reasonable a menu
> choice to
> > > > not reveal information, which after 30 seconds or so
> (and perhaps a
> > > > voice prompt), would default to revealing exact
> location. That allows
> > > > for informed choice without comprimising safety.
> > >
> > > Yes, good idea, but that's a user interface issue, not a
> protocol issue
> > > (as long as the information is available locally on the
> end system). As
> > > far as I know, user interfaces aren't specified by the
> IETF. We can (and
> > > should) say that user interfaces should be designed to allow such
> > > choices, but I don't expect this to have much effect
> beyond making us
> > > feel good about having protected privacy. Look how much effect the
> > > warnings in the MIME spec about asking users about
> executable content
> > > have had.
> >
> > Stephen Kent continues to argue that a security "protocol
> is not just
> > syntax, it's the processing part too." (Message to Robert Muskowitz
> > and saag-wg, last Friday) While my own interpretation is closer to
> > yours than his, I believe that we can specify that a user must be
> > given a choice, unless such a thing is forbidden by local
> law. As to
> > will engineers implement such a thing? I think that the
> more support
> > we can give to good implementation, the better off everyone will be.
> > I could argue that, given the number of poor prngs out
> there, RFC1751
> > was a waste of electrons. Rather, I try to ensure the standards I'm
> > involved in address the issues as best they can, and then pressure
> > people to follow them.
> >
> > > > I can clearly see cases in which I want to summon
> emergency services
> > > > without revealing that I'm the one doing so. For
> example, if I'm in
> > > > Amsterdam's red light district, I may want privacy, and
> be able to
> > > > report a street address.
> > >
> > > Yes, that's clearly a useful feature. Note, however, that
> reporting
> > > caller identity is not only used for speeding responses,
> but also to
> > > discourage prank 911 calls or, more sinister, to use 911
> to lure law
> > > enforcement into a trap. Rumor has it, for example, that
> the NYPD is
> > > very careful about following 911 calls from payphones in
> certain areas,
> > > as these have been used to get officers ambushed. Thus,
> as usual, there
> > > are multiple conflicting and legitimate objectives. Weighing such
> > > trade-offs is done by politicians, not IETF standards, as
> these are not
> > > technical issues. At best, we can provide the means to
> make good choices
> > > easier.
> >
> > There are many places where we are asked to make these
> choices in the
> > design of our protocols. The IETF and IAB have been fairly clear on
> > on the issues of security and privacy, and that protocol design for
> > the global internet should not be constrained by the laws of
> > individual countries, especially where laws vary substantially from
> > country to country.
> >
> > Asking politicians to answer the question of how they trade off with
> > their counterparts in other countries is going to prevent us from
> > standardising in time for the Phase 2 that you've referred to. We
> > need to, and are able to, make intelligent choices about
> these issues.
> >
> > (See in particular RFCs 1984, 2804)
> >
> > Adam
>
> --
> "It is seldom that liberty of any kind is lost all at once."
> -Hume
>
>
Received on Mon Aug 20 15:09:43 2001