Subject: AW: [Ecrit] requirements

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 23 Mar 2005 18:40:31 +0100

hi john, 

please see my comment inline: 

> 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.
> 
right. 

> 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.
we (the ietf) are not going to make a decision when to accept or reject
emergency calls. in fact, most people tell us that they will never reject
one. 
hence, i guess we can agree that we MUST NOT require that end users
authenticate in order to place an emergency call. 

with the discussion around location, identification of the calling party,
language, device properties, etc. we are describing what additional
information we could provide to the emergency response centers to make their
decision making easier. we are providing just a toolbox here. 

at the last ietf some people have proposed to provide additional guarantees
for location obtained via the access network. the main question is what type
of properties they these (and other to be discussed attributes) provide. 

ciao
hannes

> 
> 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