Subject: AW: [Ecrit] RE: [Ecru] requirements

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 23 Mar 2005 19:34:32 +0100

hi medhavi, 

thanks for providing this information. 

it is a good question whether a "return-routability check" at the sip layer
provides a good replacement for authentication. 
depending on the identity used for the check you either verify "is the
calling party reachable at the given ip address?" or  "is the calling party
indeed reachable at the given uri". 

ciao
hannes

> 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.
> 
> > -----Original Message-----
> > 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
> > 
> > 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
> > 
> > > -----Original Message-----
> > > 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
> > >
> > >
> > >
> > > ***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
> > > --
> > > 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
> > >
> > 
> > 
> > _______________________________________________
> > 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