Transcript PPT Version

Architectural
Considerations
for GEOPRIV/ECRIT
Presentation given by Hannes Tschofenig
Acknowledgements
I would like to thank the Geopriv/ECRIT interim meeting participants
for their time to discuss the topics presented in this slide set.
In particular i would like to thank Henning Schulzrinne, Ted Hardie,
Andy Newton, Allison Mankin and Jon Peterson.
The interim meeting minutes can be found at:
http://www.ietf-ecrit.org/Interim2005/ECRIT-Meeting-Minutes.txt
Background

A lot of discussions at the Geopriv/ECRIT Interim Meeting (New
York, May 2005):
Denial of service prevention for Emergency Services

Threat:
End host lies about location information or replays it.
Send emergency personnel to arbitrary place from everywhere in
the world.

Aspect has architectural relevance
Architectural Considerations (1/2)
Network driven Approach
SIP Proxy
911
Contact
PSAP
Phone
PSAP
Fetch
Location
Determine
PSAP
extract
location+identity+…
determine language
determine media
Query /
Response
Protocol
Distributed
Directory
48° 49' N 2° 29' E 
Paris fire department

Assumption: Network intermediary is able to obtain location of end host.
Architectural Considerations (2/2)
End-Host driven Approach
Contact PSAP
extract user
location+identity+…
determine language
determine media
PSAP
Phone
Fetch
Location
determine
PSAP location
Query /
Response
Protocol
Distributed
Directory
48° 49' N 2° 29' E 
Paris fire department
Observations

Approach (1) requires that the network intermediary knows the end
hosts location

Some architectures separate between
— Network Access Provider,
— Internet Service Provider and the
— Application Service Provider

Application Service Providers often do not have the location of the
end host.

Location information obtained by an end host via GPS or from the
network using DHCP is not cryptographically protected.
Denial of Service Threat (1/2)

Adversary places an emergency call and attaches the wrong location
information.

Constraints:
— Authentication and authorization for network access or
emergency call cannot be mandated.

Why to worry since this is already possible in today’s network?

Not quite since you can use a public phone but you attach arbitrary
location information.

Additionally, non-voice calls should be also supported.
Goals

Determine quality of emergency call in real-time (for ranking)
[does not mean that the call is malicious if various security checks
cannot be performed]

Catch adversary (later; non real-time)
How to trace back the adversary?
Depends how the adversary placed the emergency call:

Authenticate emergency caller to PSAP:
— Might require a public key infrastructure
— Deployment concerns
— Performance concerns

Asserted identities:
— Works with approach (1) (P-Asserted-ID) and
— with approach (2) if you have a separate identity provider
(SAML like scheme)

IP address:
— IP traceback mechanisms
How to determine trustworthiness of provided information?

Information received by the PSAP should be correct.
— At least not intentionally incorrect = modified by adversary.
— Entity signing information is held responsible for it.

Assumption:
— Network access provider / internet service provider signs location
information
— Easier to setup public key infrastructure for usage between
network access provider/ internet service provider and PSAP

PSAP performs the following steps when receiving an emergency call:
— path validation
— digital signature verification
— determine degree of trustworthiness into the network access
provider and internet service provider

Location signing and verifying is not a binary decision
(location, signer, etc. plays a role)
How to determine trustworthiness of provided information?
Challenges (1/2)

Signing location information by the network access provider or
internet service provider does not directly identify the end host (and
the user)

With typical network access authentication the user is not known to
a visited network provider (although it could potentially be revealed
in cooperation with the user’s home network).

In some cases even with network access authentication the user
cannot be traced back (e.g., pre-paid cards in some countries).

Without network access authentication no information about the
user is known.

If some providers do not support location signing then the benefit it
decreased.
How to determine trustworthiness of provided information?
Challenges (2/2)

Replay of signed location information is possible particularly if end
hosts cooperate to mount an attack.

How to prevent possible replays:
— Bind it to the signaling session
Easier with approach (1). (e.g., SIP: From, Contact, Date, CallID, etc.)
— If asserted location is requested before starting the signaling
session then replay protection is more difficult. Which field can
you use?
• IP address (might not be reliable source if the end host is
behind a NAT)
• Timestamp
Conclusion

There are some basic assumptions that require further
investigations. We need PSAP operators us to tell what they want!

What is more important?
— Asserted Location
— Authenticated Identity
Do you accept an emergency call* with asserted location but
without an authenticated identity?
Do you accept an authenticated emergency call* without an
asserted location?

Emergency specific authentication and authorization might be useful
(=> new credentials required)
* if the PSAP is under denial of service
Open Issues

Is is sufficient for PSAP to verify that it was signed by a “known”
entity?

How large is the number of network or internet service providers?
— Has an impact on likelyhood of trusting someone’s asserted
location.

What is the identity that is used in the certificates? (RFC 3770?)

Is it possible to get another host’s location being signed?

Can a provider be held responsible for something?
OR
Are network operators and internet service providers excited?
