draft-ietf-ecrit-trustworthy-location-02.txt   draft-ietf-ecrit-trustworthy-location-03.txt 
ECRIT Working Group H. Tschofenig ECRIT Working Group H. Tschofenig
INTERNET-DRAFT Nokia Siemens Networks INTERNET-DRAFT Nokia Siemens Networks
Category: Informational H. Schulzrinne Category: Informational H. Schulzrinne
Expires: November 25, 2011 Columbia University Expires: October 4, 2012 Columbia University
B. Aboba (ed.) B. Aboba (ed.)
Microsoft Corporation Microsoft Corporation
24 May 2011 4 April 2012
Trustworthy Location Information Trustworthy Location Information
draft-ietf-ecrit-trustworthy-location-02.txt draft-ietf-ecrit-trustworthy-location-03.txt
Abstract Abstract
For some location-based applications, such as emergency calling or For some location-based applications, such as emergency calling or
roadside assistance, it is important to be able to determine whether roadside assistance, it is important to be able to determine whether
location information is trustworthy. location information is trustworthy.
This document outlines potential threats to trustworthy location and This document outlines potential threats to trustworthy location and
analyzes the operational issues with potential solutions. analyzes the operational issues with potential solutions.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 25, 2011. This Internet-Draft will expire on October 4, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 14 skipping to change at page 4, line 14
Provider (VSP). The VSP may be located far away from the AIP and may Provider (VSP). The VSP may be located far away from the AIP and may
either have no business relationship with the AIP or may be a either have no business relationship with the AIP or may be a
competitor. It is also likely that the VSP will have no relationship competitor. It is also likely that the VSP will have no relationship
with the PSAP. with the PSAP.
In some situations it is possible for the end host to determine its In some situations it is possible for the end host to determine its
own location using technology such as the Global Positioning System own location using technology such as the Global Positioning System
(GPS). Where the end host cannot determine location on its own, (GPS). Where the end host cannot determine location on its own,
mechanisms have been standardized to make civic and geodetic location mechanisms have been standardized to make civic and geodetic location
available to the end host, including LLDP-MED [LLDP-MED], DHCP available to the end host, including LLDP-MED [LLDP-MED], DHCP
extensions [RFC4776][I-D.ietf-geopriv-rfc3825bis], HELD [RFC5985], or extensions [RFC4776][RFC6225], HELD [RFC5985], or link-layer
link-layer specifications such as [IEEE-802.11y]. The server specifications such as [IEEE-802.11y]. The server offering this
offering this information is known as a Location Information Server information is known as a Location Information Server (LIS). The LIS
(LIS). The LIS may be deployed by an AIP, or it may be run by a may be deployed by an AIP, or it may be run by a Location Service
Location Service Provider (LSP) which may have no relationship with Provider (LSP) which may have no relationship with the AIP, the VSP
the AIP, the VSP or the PSAP. The location information is then or the PSAP. The location information is then provided, by reference
provided, by reference or value, to the service-providing entities, or value, to the service-providing entities, i.e. location
i.e. location recipients, via application protocols, such as HTTP, recipients, via application protocols, such as HTTP, SIP or XMPP.
SIP or XMPP.
This document investigates security threats in Section 3, and This document investigates security threats in Section 3, and
outlines potential solutions in Section 4. Operational outlines potential solutions in Section 4. Operational
considerations are provided in Section 5 and security considerations considerations are provided in Section 5 and security considerations
are discussed in Section 6. are discussed in Section 6.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 8, line 27 skipping to change at page 8, line 27
4.1. Location Signing 4.1. Location Signing
One way to avoid location spoofing is to let a trusted location One way to avoid location spoofing is to let a trusted location
server sign the location information before it is sent to the end server sign the location information before it is sent to the end
host, i.e., the entity subject to the location determination process. host, i.e., the entity subject to the location determination process.
The signed location information is then verified by the location The signed location information is then verified by the location
recipient and not by the target. Figure 1 shows the communication recipient and not by the target. Figure 1 shows the communication
model with the target requesting signed location in step (a), the model with the target requesting signed location in step (a), the
location server returns it in step (b) and it is then conveyed to the location server returns it in step (b) and it is then conveyed to the
location recipient in step (c) who verifies it. For SIP, the location recipient in step (c) who verifies it. For SIP, the
procedures described in [I-D.ietf-sipcore-location-conveyance] are procedures described in [RFC6442] are applicable for location
applicable for location conveyance. conveyance.
+-----------+ +-----------+ +-----------+ +-----------+
| | | Location | | | | Location |
| LIS | | Recipient | | LIS | | Recipient |
| | | | | | | |
+-+-------+-+ +----+------+ +-+-------+-+ +----+------+
^ | --^ ^ | --^
| | -- | | --
Geopriv |Req. | -- Geopriv |Req. | --
Location |Signed |Signed -- Geopriv Location |Signed |Signed -- Geopriv
skipping to change at page 15, line 40 skipping to change at page 15, line 40
Where location by reference is provided, the recipient needs to Where location by reference is provided, the recipient needs to
deference the LbyR in order to obtain location. With the deference the LbyR in order to obtain location. With the
introduction of location by reference concept two authorization introduction of location by reference concept two authorization
models were developed, see [I-D.ietf-geopriv-deref-protocol], namely models were developed, see [I-D.ietf-geopriv-deref-protocol], namely
the "Authorization by Possession" and "Authorization via Access the "Authorization by Possession" and "Authorization via Access
Control Lists" model. With the "Authorization by Possession" model Control Lists" model. With the "Authorization by Possession" model
everyone in possession of the reference is able to obtain the everyone in possession of the reference is able to obtain the
corresponding location information. This might, however, be corresponding location information. This might, however, be
incompatible with other requirements typically imposed by AIPs, such incompatible with other requirements typically imposed by AIPs, such
as location hiding (see [I-D.ietf-ecrit-location-hiding-req]). As as location hiding (see [RFC6444]). As such, the "Authorization via
such, the "Authorization via Access Control Lists" model is likely to Access Control Lists" model is likely to be the preferred model for
be the preferred model for many AIPs and subject for discussion in many AIPs and subject for discussion in the subsequent paragraphs.
the subsequent paragraphs.
Just as with PIDF-LO signing, the operational considerations in Just as with PIDF-LO signing, the operational considerations in
managing credentials for use in LbyR dereferencing can be managing credentials for use in LbyR dereferencing can be
considerable without the introduction of some kind of hierarchy. It considerable without the introduction of some kind of hierarchy. It
does not seem reasonable for a PSAP to manage client certificates or does not seem reasonable for a PSAP to manage client certificates or
Digest credentials for all the LISes in its coverage area, so as to Digest credentials for all the LISes in its coverage area, so as to
enable it to successfully dereference LbyRs. In some respects, this enable it to successfully dereference LbyRs. In some respects, this
issue is even more formidable than the validation of signed PIDF- issue is even more formidable than the validation of signed PIDF-
LOs. While PIDF-LO signing credentials are provided to the LIS LOs. While PIDF-LO signing credentials are provided to the LIS
operator, in the case of de-referencing, the PSAP needs to be obtain operator, in the case of de-referencing, the PSAP needs to be obtain
skipping to change at page 18, line 48 skipping to change at page 18, line 46
9. References 9. References
9.1. Informative References 9.1. Informative References
[GPSCounter] [GPSCounter]
Warner, J. S. and R. G. Johnston, "GPS Spoofing Warner, J. S. and R. G. Johnston, "GPS Spoofing
Countermeasures", Los Alamos research paper LAUR-03-6163, Countermeasures", Los Alamos research paper LAUR-03-6163,
December 2003. December 2003.
[I-D.ietf-geopriv-rfc3825bis]
Polk, J., Linsner, M., Thomson, M. and B. Aboba, "Dynamic Host
Configuration Protocol Options for Coordinate-based Location
Configuration Information", draft-ietf-geopriv-
rfc3825bis-17.txt (work in progress), February 2011.
[I-D.ietf-ecrit-location-hiding-req]
Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A.
Kuett, "Location Hiding: Problem Statement and Requirements",
draft-ietf-ecrit-location-hiding-req-04 (work in progress),
February 2010.
[I-D.ietf-sipcore-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the Session
Initiation Protocol", draft-ietf-sipcore-location-
conveyance-08.txt (work in progress), May 2011.
[I-D.thomson-geopriv-location-dependability] [I-D.thomson-geopriv-location-dependability]
Thomson, M. and J. Winterbottom, "Digital Signature Methods Thomson, M. and J. Winterbottom, "Digital Signature Methods
for Location Dependability", draft-thomson-geopriv-location- for Location Dependability", draft-thomson-geopriv-location-
dependability-07 (work in progress), March 2011. dependability-07 (work in progress), March 2011.
[I-D.ietf-geopriv-deref-protocol] [I-D.ietf-geopriv-deref-protocol]
Winterbottom, J., Tschofenig, H., Schulzrinne, H., Thomson, Winterbottom, J., Tschofenig, H., Schulzrinne, H., Thomson,
M., and M. Dawson, "A Location Dereferencing Protocol Using M., and M. Dawson, "A Location Dereferencing Protocol Using
HELD", draft-ietf-geopriv-deref-protocol-02 (work in HELD", draft-ietf-geopriv-deref-protocol-04 (work in
progress), December 2010. progress), October 2011.
[IEEE-802.11y] [IEEE-802.11y]
Information technology - Telecommunications and information Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area exchange between systems - Local and metropolitan area
networks - Specific requirements - Part 11: Wireless LAN networks - Specific requirements - Part 11: Wireless LAN
Medium Access Control (MAC) and Physical Layer (PHY) Medium Access Control (MAC) and Physical Layer (PHY)
specifications Amendment 3: 3650-3700 MHz Operation in USA, specifications Amendment 3: 3650-3700 MHz Operation in USA,
November 2008. November 2008.
[LLDP-MED] [LLDP-MED]
skipping to change at page 21, line 5 skipping to change at page 20, line 37
[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H. and M. Shanmugam, [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H. and M. Shanmugam,
"Security Threats and Requirements for Emergency Call Marking "Security Threats and Requirements for Emergency Call Marking
and Mapping", RFC 5069, January 2008. and Mapping", RFC 5069, January 2008.
[RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", RFC 5582, September 2009. Framework", RFC 5582, September 2009.
[RFC5985] Barnes, M., "HTTP Enabled Location Delivery (HELD)", RFC 5985, [RFC5985] Barnes, M., "HTTP Enabled Location Delivery (HELD)", RFC 5985,
September 2010. September 2010.
[RFC6225] Polk, J., Linsner, M., Thomson, M. and B. Aboba, "Dynamic Host
Configuration Protocol Options for Coordinate-based Location
Configuration Information", RFC 6225, July 2011.
[RFC6442] Polk, J., Rosen, B. and J. Peterson, "Location Conveyance for
the Session Initiation Protocol", RFC 6442, December 2011.
[RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A.
Kuett, "Location Hiding: Problem Statement and Requirements",
RFC 6444, January 2012.
[SA] "Saudi Arabia - Illegal sale of SIMs blamed for surge in prank [SA] "Saudi Arabia - Illegal sale of SIMs blamed for surge in prank
calls", Arab News, May 4, 2010, calls", Arab News, May 4, 2010,
http://www.menafn.com/qn_news_story_s.asp?StoryId=1093319384 http://www.menafn.com/qn_news_story_s.asp?StoryId=1093319384
[Swatting] [Swatting]
"Don't Make the Call: The New Phenomenon of 'Swatting', "Don't Make the Call: The New Phenomenon of 'Swatting',
Federal Bureau of Investigation, February 4, 2008, Federal Bureau of Investigation, February 4, 2008,
http://www.fbi.gov/news/stories/2008/february/swatting020408 http://www.fbi.gov/news/stories/2008/february/swatting020408
[TASMANIA] [TASMANIA]
 End of changes. 11 change blocks. 
39 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/