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

[Tschofenig Hannes <[e-mail]>]

# hi brian, 
 
# thanks for raising these issues. please see my comments inline:




	From: Brian Rosen [mailto:[e-mail]] 
	Sent: Freitag, 29. Oktober 2004 14:07
	To: Tschofenig Hannes; 'James Winterbottom'; 'James M. Polk';
[e-mail]
	Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?]
	
	

	This is a good point.

	 

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

# i fully agree with you that there is always different entities with
different requirements (which are, unfortunately, often conflicting). 	 

	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.   

# i guess that the threat model is a bit more complicated (just some
preliminary thoughts): 
you need to worry about 
- the end host (which might not always be trustworthy)
- intermediate sip proxies 
- the emergency center
- entities providing the location information (e.g., dhcp server, some nodes
in the network, etc.)
- entities which just observe the communication (e.g., on a wireless link)
- entities which can actively participate in the communication (as a mitm
adversary)
	 
	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.

# the geopriv working group will be pleased to see the requirements but the
requirements document has been finalized some time ago. if there are new
requirements which lead to new protocol mechanisms (which i am not sure)
then they new work needs to be started. at the moment i, however, think that
the individual building blocks just need to be combined in a useful fashion.

 
	 

	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.

# true. that's even true today but too often some folks do not care about
this issue. one way to limit this problem is to verify (or add location
information) by the outbound proxy. this, however, has its own limitations,
as you know. 
	 

	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.

# digitally signing the location object does not prevent replay attacks.
that's for sure. however, in combination with some other mechanisms i think
that a deployable system can be developed. as an example, if you have a
location object which is not signed by the end host itself but rather by a
different entity then you can combine it with sip specific security
mechanisms (such as s/mime protection) to indicate to the emergency center
that you placed the call. 

in any case you need to differentiate between the case where the end host
generated the location object and a case where this is done by a third party
(for example because the end host does not know its own location
information). the location object needs to indicate the target identity and
this information is provided by pidf-lo:

"
   The GEOPRIV requirements [10] (or REQ for short) specify the need for
   a name for the person, place or thing that location information
   describes (REQ 2.1).  PIDF has such an identifier already, since
   every PIDF document has an "entity" attribute of the 'presence'
   element that signifies the URI of the entity whose presence the
   document describes.
" 

(section 2.1 of
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pidf-lo-03.txt) 

i think that these different aspects will be written down somewhere. (maybe
they are already covered by some of the drafts.)

ciao
hannes

	Brian

	 

	________________________________

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

	 

	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:[e-mail]] 
		Sent: Freitag, 29. Oktober 2004 08:32
		To: James M. Polk; [e-mail]
		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: [e-mail]
[mailto:[e-mail]] 
		Sent: Friday, 29 October 2004 3:07 PM 
		To: [e-mail] 
		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 
		[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-emergency 


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