Subject: RE: [Ecrit] requirements

From: "Abbott, Nadine B." <[email-masked]>
Date: Wed, 23 Mar 2005 12:28:07 -0500

John,

True, but I believe that these are accessed not by dialing 9-1-1, but by
dialing a special anonymous tip-line number; and when delivered, these calls
are indicated with an "anonymous caller id" and are not treated the same as
9-1-1 calls by the call-taker.  I don't believe that location information
can even be delivered for such calls.

Nadine

-----Original Message-----
From: John Rosenberg [mailto:[email-masked]] 
Sent: Wednesday, March 23, 2005 12:20 PM
To: Abbott, Nadine B.
Cc: [email-masked]
Subject: RE: [Ecrit] requirements

Nadine -

I agree absolutely with the validation and authentication of location info.

What I was referring to about caller identity, though, was not 
uninitialized mobiles or trying to hide by blocking your caller ID.

What I was referring to are direct-to-PSAP calls which provide anonymity to 
the caller - see GR-350 Section 4.1.2. Some jurisdictions require this type 
of access, and it's used for anonymous tip lines and the like.

John

At 11:06 AM 3/23/2005, Abbott, Nadine B. wrote:
 >John,
 >
 >This may not be to the main point of your email, but I thought some
>clarification might be in order.  >In the US, uninitialized mobiles are
allowed to initiate 9-1-1 calls without  >callback number identification,
but this is not the norm.  Caller  >identification may not be provided in a
few other special instances (e.g.,  >signaling failures, or left-in-service
lines for which 9-1-1 calling is  >supported during the transition to new
occupancy).  >But typically, even if a caller has calling identity privacy
features,  >callback number is delivered to the PSAP on 9-1-1 calls in most
>jurisdictions.  >I think that "authentication" of location information
relates mainly to  >accountability of the originating service provider
responsible for  >populating the location information.  >  >Nadine  >
>-----Original Message-----
 >From: [email-masked] [mailto:[email-masked]] On Behalf Of
>John Rosenberg
 >Sent: Wednesday, March 23, 2005 11:28 AM
 >To: Ken Carlberg; 'Tschofenig Hannes'; [email-masked]
 >Subject: RE: [Ecrit] requirements
 >
 >
 >All -
 >
 >I think the basic question being asked deals with two (or more) different
>flavors under the umbrella of Emergency Services. Two existing examples
are:  >  >  o B/E911 in the US - does not require that the "caller" be
authorized, or  >even identified (most 911 systems today are required to
provide anonymous  >access);  >  >  o GETS (Government Emergency
Telecommunications Service) in the US, which  >can only be used by
authorized users - uses PIN mechanism something like a  >calling card to
allow the caller to authenticate.  >  >I think the original e-mail was
asking for a specific requirement for ecrit  >(911 service domain) stating
that "caller" MUST NOT be required to be  >pre-authorized or to have to
authenticate in order to place an emergency  >service (e.g. 911-type) call.
>  >John  >
 >------------------------
 >John Rosenberg
 >Lucent Technologies
 >LSS Core Product Mgmt
 >LSS Emergency Services, GETS, & Regulatory Features Product Mgmt
>630-713-7162 [email-masked]  >  >  >At 10:15 AM 3/23/2005, Ken
Carlberg wrote:  > >> you might remember the presentation by james about
validation of  >location  >> information. he pointed out that access network
provides  >location  >> information to the end host in such a way that the
emergency  >response  >center  > >> is able to verify that a "trusted"
access network created the object and  >>> (maybe that this network is
indeed reponsible for the area).  >  >James  >may correct me, but I would
say that the scenario you paint above  >is one  >of authentication and
integrity in the "validation of location  >>information".  I would not
consider that a case of authorization, since  >I  >bind that security
component with usage of a service.  we may have to  >>chalk this up as a
case of agreeing to disagree.  >  >> we had some further  >discussions about
this issue in the geopriv working  >> group. i also  >consider this as part
of the authorization decision.  >> there are still a  >number of issues that
need to be investigated and  >> discussed (and i am  >not sure that i
understood all aspects;  >> the same is probably true for  >other folks as
well).  >  >I have not been following geopriv as closely as I  >should have,
so I can't  >comment on this.  >  >> there will not be a 'must  >be
authenticated' and 'must be authorized'  >> requirement for 911/etc.  >calls
(what we have heard so far in the  >> discussions).  >  >well, my  >personal
feeling is that users and information should be  >authenticated to  >offer a
measure confidence to others as to the  >validity of the user and/or  >the
information (eg, location info)  >being provided.  >  >> we should also
>discuss what the meaning of the authorization decision  >in the  > >>
context you mention (rfc 2906) is. do you think about 'user x is
>subscribed  >> i.e. was successfully authenticated' or 'user x has
>sufficient funds' or  >> 'user x is within a specific geographical area'
>etc.  >>  >> i think that most people do not make an assumption about
>authorization in  >> this particular area. i would like to know what type
of  >authorization the  >> ieprep folks consider.  >  >in my view, you are
mixing  >components of security.  a service is  >potentialy authorized and
>information in potentially authenticated  > >-- I say potentially because
the security portion may not be deployed.  >  >>I'm probably being very
picky in my terminology, but I would say that  >>ieprep does not consider a
"type of authentication" because that would  >>correlate to a solution,
which is not in the current charter of ieprep.  >  >>rfc-3689 from ieprep
provides some general requirements with respect  >to
>authorization/integrity/authentication, but the rfc is only a  >baseline
>starting point from which more specific requirements can  >be defined
within  >that group.  it can be debated how effective this  >approach was,
but that  >was the direction we took at the time.  >  >-ken  >  >  >  >
>>_______________________________________________
 > >Ecrit mailing list
 > >[email-masked]
 > >https://www1.ietf.org/mailman/listinfo/ecrit
 >
 >
 >_______________________________________________
 >Ecrit mailing list
 >[email-masked]
 >https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: John Rosenberg <[email-masked]>
Date: Wed, 23 Mar 2005 11:32:03 -0600

Nadine -

True, the caller dials the PSAP DN directly, and the ANI is 0-911-0000, but 
from that point on they are treated as normal 911 calls - analogous to ANI 
failure. How the call-taker treats the caller is outside our scope I think.

John