Subject: RE: [Ecrit] requirements

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

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:20:15 -0600

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 23 Mar 2005 15:43:52 -0500

> populating the location information.  

There may not be a service provider in the traditional sense, at least 
if you mean voice service provider. (Another instance where, I believe, 
we should try for more precise terminology in our discourse. Brian has 
suggested a few terms, something like
VSP - voice service provider [which might be a cafe or a private residence]
ISP - Internet service provider
IAP - Internet access provider)