Subject: AW: [Ecrit] requirements

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

hi nadine, 

thanks for your input. it is interesting to see that you see asserting of
location information mainly as accountability. 
you would always authorize an emergency call but, if you encounter some
problems, you want to hold someone liable for it. 
is this a correct interpretation? 

ciao
hannes
 
> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Im Auftrag von Abbott, Nadine B.
> Gesendet: Mittwoch, 23. März 2005 18:06
> An: 'John Rosenberg'
> Cc: [email-masked]
> Betreff: RE: [Ecrit] requirements
> 
> 
> 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
> 

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