Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?]

From: Tschofenig Hannes <[email-masked]>
Date: Fri, 29 Oct 2004 10:14:27 +0200

hi james, 
 
every document will have to address both privacy and security
considerations. the geopriv requirements draft gives a number of guidelines
but more work is needed when you apply it to an actual using protocol (such
as sip). the fact that you have pseudonyms is nice but still there are some
places where user names show up. for example, end-to-end security mechanisms
provide the recipient a way to authenticate you (and authorizate you based
on your authenticated identity) but if you want to experience anonymity then
the authorization functionality at the recipient is certainly more
difficult. 
 
ciao
hannes

  _____  

From: James Winterbottom [mailto:[email-masked]] 
Sent: Freitag, 29. Oktober 2004 08:32
To: James M. Polk; [email-masked]
Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?]

Hi James, 

Doesn't "draft-ietf-geopriv-pres-02" suggest that a location
server/generator is able to transmit a location to a location recipient, be
that the target itself, or someone else. I believe that this is also covered
in RFC-3693 GeoPriv Requirements. In order to be able to transmit a
location, one must first be able to determine it!!! For the purposes of
transmitting location pseudonyms are also used, so I am not sure where the
tying to a user name comes in.

What was submitted by me is a set of requirements that the authors believe
need to be satisfied in order to meet the needs of emergency service
providers. There has been no discussion of not using or varying the existing
GeoPriv rulesets.

Cheers 
James 

-----Original Message----- 
From: [email-masked]
[mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Friday, 29 October 2004 3:07 PM 
To: [email-masked] 
Subject: [Sipping-emergency] Comment about Charter [no privacy?] 

All 

In reading the charter for our new ECRIT BOF, I don't see mention of 
privacy concerns wrt the ability to track an endpoint based on some Loc 
Info Server (LIS) always knowing where that endpoint is (if nomadic or 
mobile), or tying a user(name) to a particular endpoint (regardless of what 
type it is). 

I thought privacy was agreed upon to be mentioned as a consideration? 

I know at least Jonathan and I brought it up, and I think I remember Jon 
agreeing to this consideration. 

We do not want to ignore the retention and distribution rules we so 
carefully built into the PIDF-LO 

cheers, 
James 

                                ******************* 
                 Truth is not to be argued... it is to be presented 

_______________________________________________ 
Sipping-emergency mailing list 
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-emergency
<https://www1.ietf.org/mailman/listinfo/sipping-emergency>  

_______________________________________________
Sipping-emergency mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-emergency

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 29 Oct 2004 08:07:18 -0400

This is a good point.

This points out a common tension between groups seeking authenticity and
groups seeking privacy.

The emergency call authorities reasonably want to prevent forging of
location, which could be used to direct responders away from something bad
about to happen.  Individuals do not want their location to be able to be
tracked in some circumstances.   

In North America, the tension between privacy and location authenticity is
solved with legislation: the privacy right is explicitly waived when an
emergency call is placed.  It would be interesting to know if this is not
the case in other areas.  This is a geopriv issue, but we might have to send
some requirements to them over the issue.

Recognize that automatic reporting of location is implemented because all
too often the caller does not know where they are, or is unable to
communicate where they are, to the call taker.   When you make an emergency
call, you MUST provide location, and in every jurisdiction, it would be a
crime to falsely report your location.

I would think that given the history in geopriv over this issue, that we
aren't going to get IETF to publish an RFC where not reporting location is
incompliant with a spec; we have a sufficient number of people who feel
passionately that an individual cannot be COMPELLED to report location.
This is quite easily dealt with by using SHOULD language.  The emergency
call system can choose to accept such calls or not, as local regulations
dictate.  

The most straightforward method of providing authentication would be to have
the location object signed by a trusted entity.  I've had a running dialog
with James Winterbottom and his co-authors on this subject; I maintain it is
not practical to always have a trusted entity, but let's say, for this
discussion, that there is.  If only the location object itself is signed,
and no other identifying piece of information that attaches an identity to
the location, then you can assure that the location report itself has not
been modified, but you don't know that the object represents the location of
the entity presenting it (you are subject to a replay attack).   The only
way to be assured that the location object represents the entity presenting
it would be to have a credential or other identifier in the signed object
that was verifiable by the entity receiving the call as belonging to the
entity placing the call.  I have no idea what such a credential/identifier
could be because, as I will show, the entity that could reasonably sign the
LO doesn't have any identity for the entity placing the call when it has to
sign the object; they are entirely disconnected from one another.  This
thread is about how to make sure that whatever identifier is used, it can't
be used to specifically identify a person.  That still doesn't solve the
problems of what entities could reasonably assert location validation, and
how any form of anonymous, but authenticated, location could be provided.  I
have no suggestions.

Brian

  _____  

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Tschofenig Hannes
Sent: Friday, October 29, 2004 4:14 AM
To: 'James Winterbottom'; James M. Polk; [email-masked]
Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?]

hi james, 

ciao

hannes

  _____  

Hi James, 

Cheers 
James 

-----Original Message----- 
[mailto:[email-masked]] 

All 

cheers, 
James 

                                *******************

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 29 Oct 2004 09:23:14 -0400

Brian Rosen wrote:

> aren’t going to get IETF to publish an RFC where not reporting location 
> is incompliant with a spec; we have a sufficient number of people who 
> feel passionately that an individual cannot be COMPELLED to report 
> location.  This is quite easily dealt with by using SHOULD language.  
> The emergency call system can choose to accept such calls or not, as 
> local regulations dictate. 

It's a bit more complicated than that, as there are at least three 
reasons not to provide location:

(1) The calling end system (and elements along the call path) may not 
know the location; this is obviously going to be quite common, 
particularly in the early days. Having the PSAP refuse all such calls 
seems unwise.

(2) The caller may refuse to give his location for good or bad reasons.

(3) The caller may not be at the scene of the emergency or may report a 
non-emergency-related issue and have a legitimate interest not to report 
his location or identity. (I suspect quite a few crime tips are phoned 
into 911, even though they might not be emergencies as such.)

I don't think we need to deal with (3). A PSAP could simply tell the 
caller that the call location is recorded and provide an anonymous tip 
line number.

I don't think including "sorry, I wish I could provide my location, but 
I can't" is particularly useful since bad guys will have little 
compunction about fibbing.

In addition, "providing location" is not binary. I might decide or be 
able to provide location sufficient to route the call (e.g., town 
level), but not to dispatch a fire engine (house level).

I'm not sure what to do about this. In classical 911, this is easy since 
the system can compel you to provide location.

In practice, I don't think this is as big a problem. People routinely 
call 911 from payphones or non-phase-II cell phones today, where even 
knowing the location doesn't exactly help you to find malicious callers.

The best we can probably do is to provide degrees of assurance so that 
the responder can better tell if he should be suspicious of the call and 
maybe question the caller a bit more. ("What's the name of the cross 
street? How come it's dead quiet in the background when you're on 
Broadway and 42nd street?")

> 
>  
> 
> The most straightforward method of providing authentication would be to 
> have the location object signed by a trusted entity.  I’ve had a running 
> dialog with James Winterbottom and his co-authors on this subject; I 
> maintain it is not practical to always have a trusted entity, but let’s 
> say, for this discussion, that there is.  If only the location object 
> itself is signed, and no other identifying piece of information that 
> attaches an identity to the location, then you can assure that the 
> location report itself has not been modified, but you don’t know that 
> the object represents the location of the entity presenting it (you are 
> subject to a replay attack).   The only way to be assured that the 
> location object represents the entity presenting it would be to have a 
> credential or other identifier in the signed object that was verifiable 
> by the entity receiving the call as belonging to the entity placing the 
> call.  I have no idea what such a credential/identifier could be 
> because, as I will show, the entity that could reasonably sign the LO 
> doesn’t have any identity for the entity placing the call when it has to 
> thread is about how to make sure that whatever identifier is used, it 
> can’t be used to specifically identify a person.  That still doesn’t 
> solve the problems of what entities could reasonably assert location 
> validation, and how any form of anonymous, but authenticated, location 
> could be provided.  I have no suggestions.
> 
>  
> 
> Brian

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 29 Oct 2004 11:52:14 -0400

in-line....

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Friday, October 29, 2004 8:07 AM
To: 'Tschofenig Hannes'; 'James Winterbottom'; 'James M. Polk';
[email-masked]
Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?]

This is a good point.

In North America, the tension between privacy and location authenticity is
solved with legislation: the privacy right is explicitly waived when an
emergency call is placed.   

This is only partially true, there are states that allow a user to request
that no ALI record is created for their phone number.  (Just want to make
sure we spin it correctly!)

-Marc Linsner-

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 29 Oct 2004 12:27:42 -0500

If all documents have to address privacy and security in compliance to that 
which was specifically addressed in Geopriv, and these two topics were 
already discussed on this list for inclusion in the charter, then why not 
agree to add the text?

At 08:07 AM 10/29/2004 -0400, Brian Rosen wrote:

>the case in other areas.  This is a geopriv issue, but we might have to 
>send some requirements to them over the issue.
>
>communicate where they are, to the call taker.   When you make an 
>emergency call, you MUST provide location, and in every jurisdiction, it 
>would be a crime to falsely report your location.
>
>aren t going to get IETF to publish an RFC where not reporting location is 
>passionately that an individual cannot be COMPELLED to report 
>location.  This is quite easily dealt with by using SHOULD language.  The 
>emergency call system can choose to accept such calls or not, as local 
>regulations dictate.
>
>have the location object signed by a trusted entity.  I ve had a running 
>maintain it is not practical to always have a trusted entity, but let s 
>location report itself has not been modified, but you don t know that the 
>object represents the location of the entity presenting it (you are 
>credential or other identifier in the signed object that was verifiable by 
>the entity receiving the call as belonging to the entity placing the 
>call.  I have no idea what such a credential/identifier could be because, 
>as I will show, the entity that could reasonably sign the LO doesn t have 
>any identity for the entity placing the call when it has to sign the 
>object; they are entirely disconnected from one another.  This thread is 
>about how to make sure that whatever identifier is used, it can t be used 
>to specifically identify a person.  That still doesn t solve the problems 
>of what entities could reasonably assert location validation, and how any 
>form of anonymous, but authenticated, location could be provided.  I have 
>no suggestions.
>
>
>
>Brian
>
>
>
>----------
>considerations. the geopriv requirements draft gives a number of 
>guidelines but more work is needed when you apply it to an actual using 
>protocol (such as sip). the fact that you have pseudonyms is nice but 
>still there are some places where user names show up. for example, 
>end-to-end security mechanisms provide the recipient a way to authenticate 
>you (and authorizate you based on your authenticated identity) but if you 
>want to experience anonymity then the authorization functionality at the 
>recipient is certainly more difficult.
>
>
>
>ciao
>
>hannes
>
>
>
>----------
>server/generator is able to transmit a location to a location recipient, 
>be that the target itself, or someone else. I believe that this is also 
>covered in RFC-3693 GeoPriv Requirements. In order to be able to transmit 
>a location, one must first be able to determine it!!! For the purposes of 
>providers. There has been no discussion of not using or varying the 
>existing GeoPriv rulesets.
>
>
>Cheers
>James
>
>
>[<mailto:[email-masked]>mailto:[email-masked]] 
>
><https://www1.ietf.org/mailman/listinfo/sipping-emergency>https://www1.ietf.org/mailman/listinfo/sipping-emergency 
>

cheers,
James

                                *******************