Subject: RE: [Ecrit] requirements

From: "James Winterbottom" <[email-masked]>
Date: Fri, 25 Mar 2005 03:43:50 +1100

Hey Marc,

Agree with the sentiment. Strongly recommend that we put BOTH a definition
for validated and a definition for authenticated in the document though, so
that this misunderstanding does not continue to propagate.

Cheers
James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Marc Linsner
Sent: Friday, 25 March 2005 1:57 AM
To: [email-masked]
Subject: RE: [Ecrit] requirements

So, for ecrit - we are going to work with the pidf-lo, signed or not.  It is
not the responsibility of a protocol to enforce the 'lo must be signed'
policy.  When the call arrives at a psap that requires a signed lo, they can
do with it what they wish.

A signed pidf-lo is geopriv's issue.

Ecrit will figure out how to identify an emergency call, route the call to
the psap of choice and provide a mechanism for a client to 'validate' that
the/a location in their pidf-lo is capable of reaching a psap should they so
desire.

Correct?

-Marc-

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Brian Rosen
> Sent: Wednesday, March 23, 2005 4:44 PM
> To: 'Tschofenig Hannes'; 'James Winterbottom'; 'Ciesla, Larry'; 
> [email-masked]
> Subject: RE: [Ecrit] requirements
> 
> One interesting observation on that subject is that the LIS has to 
> have a "local" component; that is, a LIS that provides location for a 
> part of Denmark has calls sent to the PSAP in Denmark.
> 
> A LIS could cover a large area, but it is serving entities that are 
> physically in the location where the PSAP that gets the calls are 
> located.
> 
> This means that the PSAP could authorize a LIS.
> More reasonably, an organization, on a national or regional basis 
> could authorize LIS's that serve that area.
> 
> Authorize, I think, means giving them a cert.  They use that cert to 
> sign the location object, which fills a couple of needs.
> 
> Having said that, I think that it is very difficult to make the 
> quality of the cert be really good, because every enterprise above 
> some size has to run a LIS, and it's pretty hard to qualify 
> enterprises.  Not quite the same as making a global PKI, but still 
> pretty tough.
> 
> I think that problem is there, but I still think the best approach is 
> to give LIS's a cert and let them sign the location (and, BTW include 
> a timestamp).
> 
> Brian
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf
> Of
> > Tschofenig Hannes
> > Sent: Wednesday, March 23, 2005 12:47 PM
> > To: 'James Winterbottom'; Ciesla, Larry; [email-masked]
> > Subject: AW: [Ecrit] requirements
> >
> > hi james,
> > hi larry,
> >
> > based on this definition i cannot write code.
> > how do you ensure that the entity that assigned location information 
> > to someone is allowed todo so? do you assume that there is an access 
> > control list that says: "if identity(access network) == "company x" 
> > then accept"?
> >
> > ciao
> > hannes
> >
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: [email-masked] [mailto:[email-masked]] Im 
> > Auftrag
> von
> > James Winterbottom
> > Gesendet: Mittwoch, 23. März 2005 18:17
> > An: Ciesla, Larry; [email-masked]
> > Betreff: RE: [Ecrit] requirements
> >
> >
> > 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
> >
> 
> 
> 
> 
> _______________________________________________
> 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