Subject: AW: [Ecrit] requirements

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

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 23 Mar 2005 14:27:23 -0500

> someone is allowed todo so? 

Allowed by whom? Do we assume that one has to have a license to provide 
such services? Who would hand out such licenses? (As far as I know, 
nobody has licensed Columbia University to provide telecommunication 
services and I guess we thus would not be able to legally provide 
campus-level location information.)

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 23 Mar 2005 16:43:44 -0500

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

> 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,
> 
> >information".  I would not consider that a case of authorization, since
> >I
>  >-- I say potentially because the security portion may not be deployed.
> >
> >correlate to a solution, which is not in the current charter of ieprep.
> >

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 24 Mar 2005 09:57:19 -0500

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-

> Brian Rosen
> Sent: Wednesday, March 23, 2005 4:44 PM
> To: 'Tschofenig Hannes'; 'James Winterbottom'; 'Ciesla, Larry';
> [email-masked]
> > >> (maybe that this network is indeed reponsible for the area).  >
> >James
> > other folks as well).  >  >I have not been following geopriv as closely
> as
> > I
> > authorization in  >> this particular area. i would like to know what
> type
> > of
> > >rfc-3689 from ieprep provides some general requirements with respect
> >to

---

From: Brian Rosen <[email-masked]>
Date: Thu, 24 Mar 2005 17:10:49 -0500

Excuse me, but in the security considerations we will have to discuss 
the effects of a fraudulant, modified, or replayed location used for 
emergency routing.  I can't imagine not making a signed location a MUST, 
even with a general discussion of the difficulty of getting a good 
cert.

Brian

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 25 Mar 2005 08:54:49 -0500

> emergency routing.  

[[ml]] agreed

I can't imagine not making a signed location a MUST,
> even with a general discussion of the difficulty of getting a good

[[ml]] What about the PSAP that will accept non-cert lo?

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 25 Mar 2005 09:09:48 -0500

> [[ml]] What about the PSAP that will accept non-cert lo?

Saying that PIDF-LO must be signed without specifying the trust model is 
the worst kind of self-delusional security specifically designed not to 
stymie black hats but rather fool the pointy-haired bosses. "Look at all 
the fancy crypto bits, and it's X.509 and uses the new-fangled 
government approved crypto standard, too - this must be really secure".

See http://www.antioffline.com/pki.txt for additional reading.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 25 Mar 2005 09:16:03 -0500

As a follow-up, you might enjoy the security services of 
http://fork.com/jjb/

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 25 Mar 2005 09:56:31 -0500

So it accepts them.  There are no protocol police.

Brian

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Friday, March 25, 2005 8:55 AM
> To: 'Brian Rosen'; [email-masked]

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 25 Mar 2005 10:13:30 -0500

The trust model is that the PSAP, or some other "local" authority, issues a
cert to the LIS, which is local.  The same authority that issues the cert is
the entity that checks the signature.

That's a very reasonable trust model, with the caveat already mentioned:
large enterprises will run LIS's and it's hard to verify the bona fides of
every enterprise claiming to be large.  One can have a couple of checks, but
it's still not going to be really iron clad.

I don't see that as a big enough problem that the value of the signature is
lost, as long as the PSAPs are aware of the issues.

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, March 25, 2005 9:10 AM
> To: Marc Linsner
> Cc: 'Brian Rosen'; [email-masked]
Nope.  I think this proposal has limited capacity to stop fraudulent
locations, but it raises the bar considerably higher than no attempt at all.
It's still subject to replay attack.  It's subject to the issues raised in
the paper about how the CA and the LIS are managed.  I think it's a lot
better than nothing.

Brian