Subject: Re: [Ecrit] requirements

From: "Ciesla, Larry" <[email-masked]>
Date: Wed, 23 Mar 2005 10:38:57 -0600

In fact, a user does not even need paid phone service for 911 to work today. Both wireline and wireless phones will allow 911 to work for unsubscribed phones.  Perhaps the notion of authorization should be viewed in the context that the entity assigning location information to a phone should be authorized to do so. 

Regards

Larry Ciesla

***This message has been sent via the Intrado Wireless Information Network.***

-----Original Message-----
From: [email-masked] <[email-masked]>
To: Ken Carlberg <[email-masked]>; 'Tschofenig Hannes' <[email-masked]>; [email-masked] <[email-masked]>
Sent: Wed Mar 23 09:28:10 2005
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: "Byron Smith" <[email-masked]>
Date: Wed, 23 Mar 2005 12:35:08 -0500

Actually many/most unsubscribed wireline phones may NOT dial 911.  State law
may apply.  It depends on the policy (and sometimes, the equipment) of the
local service provider. There are many problems with unsubscribed wireline
911, including incorrect routing and no associated ALI record.

The FCC requires unsubscribed wireless phones be able to dial 911.  However,
this is also problematic, because, in general, the PSAP cannot call back the
unsubscribed phone, and because there may be no way, in general, to trace
the "owner" of the phone.  Several PSAPs have been the victim of
multiple/recurring "crank" 911 calls from unsubscribed (anonymous) wireless
phones. It can be a serious problem.

Byron

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Ciesla, Larry
> Sent: Wednesday, March 23, 2005 11:39 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Ecrit] requirements
>
>
> In fact, a user does not even need paid phone service for 911 to
> work today. Both wireline and wireless phones will allow 911 to
> work for unsubscribed phones.  Perhaps the notion of
> authorization should be viewed in the context that the entity
> assigning location information to a phone should be authorized to do so.
>
> Regards
>
> Larry Ciesla
>
>
>
> To: Ken Carlberg <[email-masked]>; 'Tschofenig Hannes'
> <[email-masked]>; [email-masked] <[email-masked]>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 3/21/2005
>

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Wed, 23 Mar 2005 13:25:23 -0500

I saw some discussion on one of the ETSI lists on requirements and work on
handling calls from unauthorized callers (without valid USIM). I think they
are looking at it as well. Your point of having to call the caller back is
important to prevent something like a DoS attack on the emergency service
provider. Will the ability to call the caller back (which means that the
wireless SP should be able to call a phone not on its network...) and locate
the origination be enough to deter attacks that authentication may not be
necessary ? Not sure how this can be done.

-Medhavi.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Byron Smith
> Sent: Wednesday, March 23, 2005 12:35 PM
> To: [email-masked]
> Subject: [Ecrit] RE: [Ecru] requirements
>