Subject: AW: [Ecrit] security threats and requirements

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 10 May 2005 21:50:21 +0200

hi brian, 

thanks for your comments. many of them have been addressed by henning. let
me add a few small remarks. 

> -----Ursprüngliche Nachricht-----
> Von: Brian Rosen [mailto:[email-masked]] 
> Gesendet: Montag, 9. Mai 2005 15:38
> An: Tschofenig Hannes; [email-masked]
> Betreff: RE: [Ecrit] security threats and requirements
> 
> 
> 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.  
the threat about configuration data is not supposed to address your
corruption and masquerading of a database. 
in fact, i guess we should spent more text on the threat for the database. 

the problem with these types of threat documents is (and i know it already
from another document) that you have to stay at a pretty high level because
you cannot address specific solutions and protocols AND you cannot assume
that some security protection is already there (since the purpose of the
threat document is defeated partially). 

i have no good answer how to provide a clear balance between the threats
that are really important and those how are pretty obvious and addressed in
every security related document. 

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

if i understood you correctly then this is also just a variation of the
other one and a different party that fetches the location information. in
umts based networks, for example, the network knows the location info of
their subscribers  and protocols executed between entities in the networks
(location client and location server) exchange information about the end
host. 

> 
> 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 second sentence is indeed not a sentence. my fault.

the whole paragraph was trying to point to the fact that that authorization
needs to be considered. 
a digital signature is fine and it allows you to determine who signed it. 
it does not immediately allow you determine whether this is indeed someone
who is provider that is allowed to assert location information. 

i don't know whether it makes sense to even say that a particular provider
is allowed to authorize location for a particular area only. 
(there are certainly a number of problems particularly if we consider moving
networks etc.)

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

i guess we should describe what we mean by database. 
i guess you think mostly about your "Master Street Address Guide" database. 

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

additionally, one needs to consider the discovery aspect. 
if your discovery procedure returns you the wrong psap then the subsequent
authentication only ensures that you talk to the psap (but it is still the
wrong one).

whether the psap is indeed a legitimate psap is also an authorization issue.

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

maybe

regarding the long paragraph below: 
i read your long discussion with henning about the access infrastructure
provider, etc. 

i have no particular good suggestion for the terminology. maybe we can use
the terminology from other places, for example:

"
 ASP
      Access Service Provider.  A network operator that provides direct
      IP packet forwarding to and from the end host.
"
taken from section 1.3 of
http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap-ps-02.txt

this definition might not be perfect either but the mobile ip folks are
happy with it. 

> 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

ciao
hannes
> 
> 
> > -----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,
> > 
> > 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-securit
y-threats-
> 00.t
> xt
> 
> ciao
> hannes
> 
> _______________________________________________
> 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: "Brian Rosen" <[email-masked]>
Date: Tue, 10 May 2005 17:02:28 -0400

Hannes

See inline, edited for brevity

> every security related document.
I think it is quite clear that you need some kind of database to translate
location to PSAP.  When you do the translation, how you do it, what the
translation results in are not decided, but I don't think there is any other
way to determine which PSAP gets the call.  Therefore, I think you are quite
safe in discussing the database as an entity in this document.

> (location client and location server) exchange information about the end
No, this was a reference to the text that says:
  o  Location Information is asserted by the Access Infrastructure
      Provider.  As such, the end host might use GPS but uses a protocol
      to allow the network to assert the location information.  This
      approach also has its limitations if the coverage area of the
      wireless network is fairly large.
The approach doesn't have limitations with large coverage areas except in
cases like satellites.  With mobile systems, the coverage area may be large,
but it is broken into cells, which are small.  You can get gross location
from the tower serving the cell, and then (later in time) you get assisted
GPS (also using the tower, for the assist signals), and the result could be
that the network, not the endpoint, has location.

Satellite systems can't assist, and have huge footprints; your statement
would be correct in that instance.

> (there are certainly a number of problems particularly if we consider
I agree with this.  It may be that a PSAP has a list of AIPs that it knows
about and treats locations signed by others with more suspicion than those
signed by AIPs it knows.

> i guess you think mostly about your "Master Street Address Guide"
Not really, in the sense that the MSAG is used for validation.
A database derived from the MSAG (in the North American case anyway) would
be used to make a routing decision, as above.  That's the database I meant.

There is a threat on the validation database, but it's no where near as
sensitive as that of the routing database.  It could be that the validation
database and the routing database are one and the same.  I in fact propose
that they are, but for the purposes of this document, I think we only need
discuss the routing database.

> authentication only ensures that you talk to the psap (but it is still the
Yes, that is true.  It would be interesting to mitigate that threat.  
I can think of ways to do that (the route yields a URI, the endpoint could
insist on authentication from the PSAP within the domain the URI is directed
to, if, for example, the cert for that domain was in the DNS.
I think that is a threat worth distinguishing in the document.

I think that threat is no where near as significant as impersonating a PSAP
at all.  It's pretty likely that if, somehow, you get to the wrong PSAP, but
you get to a legitimate PSAP, that they can get your call to the correct
one.  If an attacker wants to prevent you from getting help, they would
really want to impersonate a PSAP illegitimately.

> whether the psap is indeed a legitimate psap is also an authorization
Yes

> this definition might not be perfect either but the mobile ip folks are

I'd prefer to stick with Access Infrastructure Provider.  Consider, for
example, a DSL provider like Verizon wholesaling IP services to an ISP like
Earthlink.  Verizon owns the DSLAM, the BRAS, etc.  It is the only entity
that knows where you are.  It can tell Earthlink, but Earthlink has no other
way to determine location.  I would say Verizon is the AIP, Earthlink is the
ISP.  Who is the ASP?

Also, ASP=Application Service Provider, a very unfortunate acronym
collision.