Subject: [Ecrit] security threats and requirements

From: Tschofenig Hannes <[email-masked]>
Date: Mon, 9 May 2005 11:48:41 +0200

hi all, 

we have not seen much input on the security threats and requirements so far.

hence, we (henning, raj and myself) have tried to work on a document to
capture a few aspects:
http://www.ietf-ecrit.org/cache/draft-tschofenig-ecrit-security-threats-00.t
xt

ciao
hannes

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

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 9 May 2005 09:38:26 -0400

Thanks for working on this.

On the threat side, I think you have not explicitly covered corruption of,
or masquerading as the database.  There is wording about corruption of
configuration information, which, depending on how the database is used,
could be included.  If you think of it as a run time lookup (location in,
URI out) it's not configuration data.  There is text in the Impersonating a
PSAP threat that discusses how corruption of or impersonating the database
would allow impersonating a PSAP, but those are two threats.  

You have covered denial of service attacks on the database adequately.

In the 5.3 location spoofing section, there is some text talking about the
coverage area of a wireless network.  While this is true of some systems
(geosynchronous satellites, for example), it is less true in more common
cases, where you may have access to the "tower" location currently serving
the AIP subscriber.

More on that below.

I can't make any sense of this bullet point:
      The recipient of the asserted location information MUST have a way
      to verify that the asserting party is indeed authorized to create
      such an assertion.  As such, authentication is insufficient if not
      further authorization decision can be associated to the
      authenticated identity.

The second sentence isn't a sentence, and I'm unable to guess what you are
talking about.

The discussion which follows seems to me more applicable to identity
spoofing than location spoofing.  I guess they are related in that if
someone spoofs location, you'd like to be able to find out who it was that
did it, but it's a pretty tenuous connection.

In the section on impersonating a PSAP, you have a discussion about
impersonating the database.  These are two independent entities.  Both
threats exist, and must be considered separately.  The text is actually
about impersonating the database.  A security requirement to mitigate the
threat of impersonating the PSAP is to have a way to authenticate that the
UA answering the call is in fact a legitimate, and duly authorized PSAP.
The number of PSAPs is small enough, and they are already creatures of
government, so that the idea that we could create a PKI covering them seems
doable, for example.

I'd like to explore the issue of location spoofing a little more.
I make the following observation:
	There is ALWAYS an Access Infrastructure Provider
In almost every case, the AIP is actually some kind of carrier.  In a very
small number of cases, an enterprise can create a path that does not use a
carrier (they can use a free space laser for example).

However, the carrier is not always in a position to supply accurate enough
information.  An easy example is an enterprise PBX where the enterprise
knows building, room and floor information, but the AIP doesn't.

This leads me to suggest that we consider always requiring an AIP provided
location, which may be supplemented by another entity, such as an
enterprise.  Since AIPs are local, the local authorities could reasonably
provide them with a CA path that is verifiable.

In cases where the AIP is not providing an IP service, but merely a circuit,
the location would have a very long effective lifetime, and could be sent
from the AIP to the enterprise via an offline mechanism or email. 

In a typical residential broadband case, the AIP normally provides location.
A sophisticated home owner could provide room level location supplementary
to that.

A typical small enterprise would be the same.

A medium or large enterprise with a single site would work the same, but
depending on local ordinance, may be required to provide room level
location.

A multisite enterprise using IP services from AIPs would get the location
from the AIP periodically.  This would include a branch facility.  The
enterprise may have to select from a portfolio of authenticated location
objects, one per site, that it obtains from its AIPs, adding its own
building/room/floor data. 

The case of enterprise using a bare bit transport facility with no IP
service would get a long-lived location off line from the AIP of that
facility.

In the case of an actual private circuit, the local authorities may sign the
enterprise site cert, which it then uses.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Tschofenig Hannes
> Sent: Monday, May 09, 2005 5:49 AM
> To: [email-masked]'
> Subject: [Ecrit] security threats and requirements
> 
> hi all,
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 09 May 2005 21:12:09 -0400

> cases, where you may have access to the "tower" location currently serving

I think in general, spoofing needs to be made more precise: "wide-area 
spoofing", i.e., "caller in Iowa can summon police to address in 
Florida" and 'local-area' spoofing, i.e., limited to a few miles.

> The second sentence isn't a sentence, and I'm unable to guess what you are

I think this is best deleted.

> did it, but it's a pretty tenuous connection.

We should probably make a more explicit connection. There are layers of 
defense:

- prevent wide-area spoofing (solves the difficulty of prosecuting some 
guy in Russia in France)

- increase accountability (if spoofing occurs, there's a reasonable 
chance that the person can be brought to justice or at least that future 
calls from the same person are considered suspect)

- prevent local-area spoofing (prevent somebody who is not in place X 
from pretending to be there)

- prevent local-area cloning (prevent person from pretending to be in 
place X if they were actually there a while ago)

> knows building, room and floor information, but the AIP doesn't.

In many cases, the distinction between enterprise and carrier is dicey. 
Columbia University is an end user, but it is not fundamentally 
different from an ISP (and probably has more users than a large fraction 
of them). By the same token, the local ISP that serves Smalltown, KS, 
but gets its bandwidth from a T1 provider wouldn't be an AIP, either.

Columbia's service area is small, but there are state university 
campuses that probably exceed the service area of many small WiFi or DSL 
ISPs.

As far as I know, you don't need a license (beyond maybe a business 
license) to be an ISP, including one that offers WiMax or dial-up services.

> enterprise site cert, which it then uses.

Rather than assuming a single AIP, I think a hierarchy is much more 
generic and avoids silly definitional discussions as why Bob's Corner 
DSL & Tackle is an AIP and Ohio State University isn't.

As you note, each provider of IP or circuit connectivity provides a 
signed location blob, in some fashion, to the downstream customer. That 
way, if Bob's Corner DSL & Tackle isn't trust, but its upstream provider 
is, at least wide-area location fraud is made less likely.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 9 May 2005 21:54:14 -0400

Henning

Your responses seem very reasonable.  I'm not sure if we need more than two
levels of hierarchy, but I suppose we might as well make it general and
allow for it.

One has to differentiate between an AIP and an ISP.  One entity can be both,
of course.  The difference is that the AIP actually owns the infrastructure,
and actually can determine where you are.  The issue is, the AIP may not
have any relationship with, and cannot provide any path to the subscriber.
The ISP can.

The question becomes, do you just pass through the location from the AIP to
the ISP to the subscriber, or do you create a transitive trust relationship
so that the AIP tells the ISP and the ISP tells the subscriber the location.
It's a question of who signs the location the subscriber gets, the AIP or
the ISP.

I like the former, because I really worry how we do the CA chain.  The
latter is more attractive to the ISP of course.

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Monday, May 09, 2005 9:12 PM
> To: Brian Rosen
> Cc: 'Tschofenig Hannes'; [email-masked]
> Subject: Re: [Ecrit] security threats and requirements
> 
> Brian Rosen wrote:
>