Subject: RE: [Ecrit] requirements

From: "James Winterbottom" <[email-masked]>
Date: Thu, 24 Mar 2005 04:16:38 +1100

Larry,

That is the definition that I have been using.

Cheers
James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ciesla, Larry
Sent: Thursday, 24 March 2005 3: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

***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
_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit