Subject: Re: E911 and appliances

From: Christopher Sipes <[email-masked]>
Date: Mon, 20 Aug 2001 14:25:45 -0400

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: [email-masked] | 
617.613.6009 ||

Adam Shostack <[email-masked]>
08/20/2001 01:39 PM

        To:     Henning Schulzrinne <[email-masked]>
        cc:     Andrew Daviel <[email-masked]>, [email-masked]
        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

---

From: Christopher Sipes <[email-masked]>
Date: Mon, 20 Aug 2001 14:33:16 -0400

Exactly!  It's not truly important, nor necessarily in the scope of what 
it is we're attempting to accomplish here that we know who made the 
call....we simply need to know WHERE the call was made from!
Chris

"Rosen, Brian" <[email-masked]>
08/20/2001 02:30 PM

        To:     "'Christopher Sipes'" <[email-masked]>, Adam Shostack 
<[email-masked]>
        cc:     [email-masked], [email-masked], [email-masked]
        Subject:        RE: E911 and appliances

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:[email-masked]]
Sent: Monday, August 20, 2001 2:26 PM
To: Adam Shostack
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: E911 and appliances

 
        To:        Henning Schulzrinne <[email-masked]> 
        cc:        Andrew Daviel <[email-masked]>,
[email-masked] 
        Subject:        Re: E911 and appliances

choices
have

Adam

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 20 Aug 2001 17:22:37 -0400

So you think that geopriv must define the user identity
of the consumer of location information?

I have reviewed the charter.  It does not say anything about
defining user identification.  

Each protocol that uses this object will have a notion of
"user".  We have to respect that notion, and we definitely
can't redefine it, or even overlay our own definition.

It's completely out of hand to define the object as having
a user identifier in it; the form and specification requirements
of such an identifier presupposes more than we can assume.
It will be, in almost every case, duplicative of other information
the protocols already supply.

Likewise, we can't specify anything about the actual authentication
mechanism.  You can say it has to have one, but that might range
from a username/password to a two factor token, to a smoke signal;
If the device has an appropriate authentication mechanism (appropriate
to its circumstances), then it ought to be able to transfer location
information.

Brian

> From: Randy Bush [mailto:[email-masked]]
> Sent: Monday, August 20, 2001 4:42 PM
> To: Rosen, Brian
> Cc: 'Adam Shostack'; 'Christopher Sipes'; [email-masked];
> [email-masked]; [email-masked]
> > Write that down in the security considerations section.
> > This group needs to be focused on location.
> 
> this is not true.  please review the charter.  this wg is 
> specifically about
> privacy and security.
> 
> randy
>