Subject: RE: crypto delay (Notes from Non-meeting)

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 02 Apr 2002 07:59:39 -0500

Ever waited for help?

A second is a very long time, a VERY long time when you need help.
Yes, the RESPONSE (actual people) takes minutes or longer, but
you usually get an answer from an emergency center in a second or so.

I think you can assume your requirement is something on the order of
250 ms if there is in fact an authentication requirement for emergency
calls.  That's pretty long, but I suspect we won't get too many yelps
over it.  But... keep reading.

The kind of information you need to deal with false alarms doesn't involve
crypto authentication with the end device that this spec will deal with.
There are other mechanisms that are applicable.  

Can you cite any evidence that authentication of the emergency center by
the end device is a requirement?  

I don't think strong authentication is a requirement for providing location
with emergency calls.  I'm pretty sure the requirement is actually that
even if any authentication fails you must supply location on an emergency
call.
I'm not opposed to trying to get reasonable two way authentication done
as long as the call goes through, with location, in under a second, 
without any user action, even if authentication fails.  We can put up some 
kind of caution display maybe.

Brian

> -----Original Message-----
> From: Andrew Daviel [mailto:[email-masked]]
> Sent: Tuesday, April 02, 2002 12:34 AM
> To: Rosen, Brian
> Cc: [email-masked]
> Subject: RE: crypto delay (Notes from Non-meeting)
> 
> 
> On Wed, 20 Mar 2002, Rosen, Brian wrote:
> 
> > 	3) Impractical to use
> > 		takes seconds to verify the signature on the
> > 		processors in the devices. Cannot add a second
> > 		to post dial delay
> 
> 
> Just how much time is considered important in emergency calls ?
> If there are humans in the loop who don't know each other, or maybe
> even speak the same language fluently, we're talking tens of 
> seconds at
> least, maybe minutes. Emergency services can't put a response together
> that fast, in any case. A few seconds taken to authenticate a location
> and reduce the incidence of false alarms is going to save 
> time and lives
> in the long run.
> There is perhaps an issue if the caller believes the 
> equipment is broken
> and tries to reconnect, or abandons it altogether. This might 
> be obviated
> by some display or audible feedback of call/authentication progress.
> 
> 
> -- 
> Andrew Daviel
> 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 03 Apr 2002 08:58:31 -0500

Ugh, yes, how silly of me.  

Today, routing is based on the trunk line you place the call on.  That won't
work if the Internet is the trunk - you have to route based on location.
Duh!

By the way, it means that location has to be sent in such a way that the SIP
element(s) that make the routing decisions is able to look at the
information.
This means that it must have the key for any crypto.  That complicates
both authentication and confidentiality.

Well, that's a pretty hard requirement - routing must be based on
location, thus it must be in the first (INVITE) message, and has to
be decryptable (quickly and with great reliability) by routing 
elements (proxy servers) along the path.  We've agreed among
the folks working on emergency calls in SIP that we will have few such
elements (so that emergency calls are not dependant on very many things
working), but it will be more than one element in some cases for sure.

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, April 03, 2002 8:45 AM
> To: Rosen, Brian
> Cc: 'Andrew Daviel'; [email-masked]'
> Subject: Re: crypto delay (Notes from Non-meeting)
> 
> 
> I don't think that's a viable option. The location information is used
> for two different things:
> 
> - selecting the appropriate emergency call center that handles a
> particular geographic region (PSAP in the US);
> 
> - providing the emergency call center with user location information
> 
> Clearly, the first requires location information as part of the call
> setup and cannot be deferred until later in the call.
> 
> > 
> > I'll conceed the point that it's possible to have the 
> location information
> > come later than the call completion.  That is undesirable (because
> > it is actually very interesting to route the call in the 
> emergency center
> > based on location, something not possible now), but it's 
> concievable.
> > It's also not a great way to deal with in in SIP - rather 
> than simply
> > shoving the location in the INVITE, we have to create a mid 
> call dialog.
> > That is also possible, if undesirable.
> > 
> > Brian
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 03 Apr 2002 16:44:29 -0500

Well, I'd love to take emergency calls off the table in this
group and just go do what we need in SIPPING, but that's not
the way the AD's see it.  I also see the point that there really
should only be one way to send location.  I think that there are
quite a few uses for location that don't have much of a privacy
concern, and a lot more where the concerns will be addressed by
contract rather than by mechanism.  It's really hard to get our
arms around the disparate requirements without getting one
end (speed, simplicity, efficiency) or the other (very fine
grained control with very strong protection) upset.

The "low" end wants most of the mechanisms optional, the "high"
end doesn't.  That seems to be the nut of the problem - what
is mandatory to implement and even, a new concept, what is
mandatory to use.

Compromise on privacy seems to be hard to find.

I've been working on it over a year, I'll keep working at it :)

Brian

> From: Adam Shostack [mailto:[email-masked]]
> Sent: Wednesday, April 03, 2002 9:51 AM
> To: Rosen, Brian
> On Wed, Apr 03, 2002 at 08:27:56AM -0500, Rosen, Brian wrote:
> > > Acatually, I'm not sure whey we spend so much time discussing the
> > > E911 scenarios, though I'm clearly guilty of doing so myself. 
> > > The reaction
> > > time thing just caught my eye.
> > > 
> > One of the "users", probably the first user, of the geopriv object
> > is emergency calls in SIP.  The requirements for emergency 
> calls at the
> > top level are pretty straightforward, but are clearly subject to
> > interpretation as you dig down. 
> 
> Perhaps this is a mistake?  I think that emergency calling is complex,
> and I'm far more concerned about my non-emergency privacy.
> 
> (I do think there is a security concern, which is that if I send your
> internet phone a hyperlink of the form  "img src=tel:sos" you may hand
> out your location without the same meaning as actually dialling 911.
> We likely can't cope with this at the protocol level, but should note
> it in the security concerns section, and suggest that turning off
> privacy preference should be based on user action...)
> 
> > Emergency callers have some expectation of privacy.  That 
> expectation
> > is presently pretty limited.  There is no harm in providing a higher
> > level of privacy, provided that you don't screw something 
> up.  Response
> > time is one of those things that can be screwed up.  
> Phones, in general,
> > have fairly puny processors.  SIP phones have beefier 
> processors than
> > first gen cell phones, and 3G cell phones have processors capable of
> > non-trivial crypto, but I think we have to keep "fraction 
> of a second 
> > on embedded cpu" goals when we make crypto choices.  If we 
> are forced
> > to choose between increased security and increased response time on
> > emergency calls, it makes sense to me to choose increased 
> security up 
> > to the point where on a typical SIP phone or 3G handset, you either 
> > overflow limited memory, or more likely limited MIPS.  The 
> latter is the 
> > "fraction of a second" kind of thing.  I'm presently 
> worried about it,
> > but there are others who think there are solutions that achieve
> > strong assurances within the kinds of time/MIPS/Memory constraints
> > we deal with.  I'm certainly not oppossed to trying.
> 
> I'm also interested in trying, and would like to throw out the
> suggestion that we might specify a level of crypto which is secure,
> and offer nothing on slower processors.  That would make sense if we
> worry about roll-back attacks, and the ongoing cost of having weak
> crypto in the system.
> 
> Adam
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 03 Apr 2002 17:01:23 -0500

> Now on to other things..
> 
> What is the location object be are all talking about ?  XML? 
> ASN.1 <just 
> kidding>
Oh, I think XML is pretty good.  Generally, I think we plan to copy
something that works, although we have some issues others may not have
to deal with.

> 
> What is the semantical expression of location object the PSAP needs? 
> Typically it keys a database look up based on TN to address.  
>  PSAP address 
> databases are simply subsets of LIDB or DA information 
> supplied by the 
> LEC's this is now complicated by the mobile environment where formal 
> Lattitude and Longitude are used ..again keyed to address.
My thinking is that the object has both lat/lon/altitude as well as
planet/country/state/county/city/street/building/floor/room/cube, with
translation flags.  In the emergency call scenario, you start with one, 
translate to find the other if you can, look up the lat/lon in the 
database to find which PSAP, and send both to the PSAP.

(security note - translators muck with the data; have to be in the
trust loop).

> 
> So in those environments where E.164 addressing is uesd that is a 
> requirement...not we have the problem of sip URI's
Yeah, for now you actually send the E.164.  We may need to create a database
of E164s to PSAP (I hope not - depends on the gateway network architecture)
Note to you privacy folks that in this case E.164 = location - there is
an existing database that translates E.164 to street
address/building/floor/...

> 
> Now what other paramaters does it need to transmit?
> 
> TTL?
Oh, cute, I like it! 

> 
> Confidence  Factor ? By this I mean ..whatever system generates the 
> location information may be able to transmit its Confidence in the 
> reliability of the data. This might be useful in those cases 
> where L/L 
> triangulation is difficult or is unable to reach pinpoint accuracy.
Yeah, the whole object actually needs an accuracy estimate in it as
well as a confidence.  The spec needs a way to intentionally degrade
accuracy, but that's another story.

> 
> I'm just thinking out loud about what could or should not be 
> included in 
> the object.
Well, we have discussed previously that you may need a time stamp.
Some folks want motion vectors
There are things associated with the datum used when you have lat/lon
The translation thing is really more than a flag; you probably want
some kind of identifier (signature in some cases) of who did the translation

I'd love to actually start working on that stuff - it's real engineering,
and we can actually get it done in a finite period of time. 

Brian

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sat, 06 Apr 2002 10:50:47 -0500

>> > What is the location object be are all talking about ?  XML?
...
>geopriv presumably is a discussion of two distinct issues physical 
>location and privacy..so it stands to reason that the object under 
>discussion may have two distinct features ..A. a semantical representation 
>of physical location and a separate but distinct privacy object that 
>describes the privacy policy to be used in association with the location 
>object.
...
>either linked to or imbedded in the object. I need to re read some of the 
>W3C work on P3P to see is there is something that can be snarfed up and reused.
>
>http://www.w3.org/P3P/

I'm tuning in late. If Haitao Tang or Mari Korkea are here, "hi".

XML has an advantage, P3P offers a schema.

However, the motivation for the schema applied to non-DOM objects
(e.g., the http state mechanism, aka "cookies")
arose from a P3P-esque label scheme applied just to cookies, in the
now expired draft-jaye-http-trust-state-mgt-NN.txt.
Policies can be both P3P-esque, and processed simpler than wf or wf+v xml.

ASN.1 has an advantage, TSP (rfc3161) uses it. The PKI uses it. PGP uses it.

...

Location, State, and {data collection|privacy}

It isn't just where the end-point is (absolute or relative), but also when
it is. State is an interesting part of the problem.

The problem with decoupling location from privacy is that privacy either
is something fairly abstract and resembling a AAA statement about the
mobile computer system, or it is something jurisdictionally specific and
subject to change if the end-point's location is capable of proof. With
luck the first (mechanism) can express the second (policy).

I mention proof because it seems to me that that also is an interesting
part of the problem.

...

See draft-ietf-provreg-epp-06.txt for one go at snarf-and-reuse.

Other resources are the W3C's Mobile and P3P workshops:
http://www.w3.org/Mobile/posdep-workshop.html
http://www.w3.org/P3P/mobile-privacy-ws

Cheers,
Eric

---

From: Richard Shockey <[email-masked]>
Date: Thu, 04 Apr 2002 11:19:34 -0500

>something that works, although we have some issues others may not have

I would agree but then it brings up the subject of XML parsers in low power 
/ low horsepower devices like cellphones

I thought the core consensus in the non BOF BOF is that of what we are 
dealing with is a object and not a protocol. Protocols may use the location 
object but we are not defining how they should use it. How SIP might use a 
location object is a SIP issue ..not a geopriv one..however after the 
ENUM/SIP discussions it becomes clear the lines of discussions start to 
blur very quickly :-)

geopriv presumably is a discussion of two distinct issues physical location 
and privacy..so it stands to reason that the object under discussion may 
have two distinct features ..A. a semantical representation of physical 
location and a separate but distinct privacy object that describes the 
privacy policy to be used in association with the location object.

Either the privacy policy is imbedded in the location object ..or the 
object contains a pointer to some other privacy object.

This looks more and more like a vCard vCalendar like problem statement all 
the time ..which simplifies the requirements and work plan.

>(security note - translators muck with the data; have to be in the

and or first preform the PSAP look up hand off to a proxy and then you give 
the PSAP what you have ..in the interest of speed and assume it has the 
DB's necessary to translate but some of these requirements are 
jurisdictional its just that the object need to be able to express a 
variety of options.

>of E164s to PSAP (I hope not - depends on the gateway network architecture)

those exist its generally maps LATA boundries to NXX prefixes..I'm not sure 
how the Europeans do it.

>accuracy, but that's another story.

but this the right track we need to consider in requirements

>Some folks want motion vectors

oh cool .. yes motion relates to accuracy or perhaps last two known points 
of location in order to reference direction ... oh this gets fun ..its not 
just LL but direction SSE NNW ..

>some kind of identifier (signature in some cases) of who did the translation

excellent point

>and we can actually get it done in a finite period of time.

I agree ... there is no "protocol" here ..just data objects one is location 
and maybe motion the other is a privacy policy object that is either linked 
to or imbedded in the object. I need to re read some of the W3C work on P3P 
to see is there is something that can be snarfed up and reused.

http://www.w3.org/P3P/

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.biz>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<