Geopriv J. Winterbottom Internet-Draft M. Thomson Intended status: Standards Track Andrew Corporation Expires: May 7, 2009 H. Tschofenig Nokia Siemens Networks R. Barnes BBN Technologies November 3, 2008 HELD Identity Extensions draft-winterbottom-geopriv-held-identity-extensions-07 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 7, 2009. Winterbottom, et al. Expires May 7, 2009 [Page 1] Internet-Draft HELD Identity November 2008 Abstract When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP Enabled Location Delivery (HELD) specification, it uses the source IP address of arriving message as a pointer to the location determination process. This is sufficient in environments where an Target's location can be determined based on its IP address. Two additional use cases are addresses by this document. In the first, the source IP address in the request is not the only identifier for the Target. In the second, an entity other than the Target requests the Target's location. This document extends the HELD protocol to allow the location request message to carry additional identifiers assisting the location determination process. It defines a set of URIs for Target identifiers and an XML containment schema. This extension is used in conjunction with HELD to provide Target identification, and set of criteria of when to use this extensions are provided. Examples and usage in HELD message syntax are also shown. Winterbottom, et al. Expires May 7, 2009 [Page 2] Internet-Draft HELD Identity November 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Identity Extension Details . . . . . . . . . . . . . . . . . . 6 3.1. URI Definitions . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. MAC Address URI . . . . . . . . . . . . . . . . . . . 6 3.1.2. IP Address URIs . . . . . . . . . . . . . . . . . . . 6 3.2. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5.1. Location Configuration Protocol Requests . . . . . . . . . 12 5.2. Third Party Requests . . . . . . . . . . . . . . . . . . . 12 5.3. Distinguishing LCP Requests from Third Party Requests . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 14 6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 14 6.3. Identifier 'type' Attribute values . . . . . . . . . . . . 15 6.4. URI Type Attribute Values . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative references . . . . . . . . . . . . . . . . . . . 18 8.2. Informative references . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Winterbottom, et al. Expires May 7, 2009 [Page 3] Internet-Draft HELD Identity November 2008 1. Introduction Protocols for requesting and providing location information require a way for the requestor to specify the location that should be returned. In a location configuration protocol (LCP), the location being requested is the requestor's location. This fact can make the problem of identifying the Target simpler for LCPs, since IP datagrams that carry the request already carry an identifier for the Target, namely the source IP address of an incoming request. Existing LCPs, such as HELD [I-D.ietf-geopriv-http-location-delivery] and DHCP ([RFC3825], [RFC4776]) rely on the source IP address, and possibly lower-layer identifiers to identify a Target. Aside from the datagrams that form a request, a location information server (LIS) does not necessarily have access to information that could further identify the Target of the request. In some circumstances, as shown in [I-D.ietf-geopriv-l7-lcp-ps], additional identification information can be included in a request to identify a Target. This document extends the HELD protocol to support the inclusion of additional identifiers for the Target in HELD location requests. The identifiers are defined as URIs that include a range of different types of identification information. Finally, an XML schema is defined that provides a structure for including these identifiers in HELD requests. An important characteristic of this addition to the HELD protocol is that is also expands the potential scope of HELD beyond that of an LCP. The scope of an LCP is limited to the interaction between a Target and a LIS. That is, an LCP is limited to the Target retrieving information about their own location. With this addition, third party location recipients (LRs) are able to make requests that include identifiers to retrieve location information about a particular Target. The usage of HELD for purposes beyond the Target-LIS interaction obviously introduces a new set of privacy concerns. In an LCP, the requester is implicitly authorized to access the request location information, because it is their own location. In contrast, when a third party LR requests a Target's location, the LR MUST be explicitly authorized. Establishing appropriate authorization and other related privacy concerns are discussed in Section 4. Winterbottom, et al. Expires May 7, 2009 [Page 4] Internet-Draft HELD Identity November 2008 2. Terminology This document reuses the term Target, as defined in [RFC3693]. This document uses the term Location Information Server, LIS as described in [I-D.ietf-geopriv-l7-lcp-ps]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Winterbottom, et al. Expires May 7, 2009 [Page 5] Internet-Draft HELD Identity November 2008 3. Identity Extension Details This section defines the details of the schema extension for HELD to support the inclusion of a Target identity in the form of a URI or typed-token. A set of URI definitions that can be used to specify these identities is also provided. 3.1. URI Definitions The URIs defined in this section are designed to identify a Target; they do not identify measurements or sighting data associated with a Target, such as the switch and port information to which the Target is attached. This information may, for example, be acquired using DHCP relay information [RFC3046] or LLDP [LLDP]. Device measurements and sighting data are described in [I-D.thomson-geopriv-held-measurements]. The identity provided may be transitory, such as an IP address that is leased from a DHCP server pool. The URIs in the following sub-sections are defined using ABNF (augmented Backus-Naur form) described in [RFC2234]. 3.1.1. MAC Address URI A MAC URI represents the media access control address of the Device, as defined in the IEEE 802 series of specifications. The ABNF for this URI type is defined as: mac-uri = "mac:" 2*2HEXDIG 5*5macdig macdig = "-" 2*2HEXDIG MAC URIs can be used in the same manner as is suggested by the undefined "mac:" URIs used in examples in RFC 4479 [RFC4479]. An example of its use is provided in Figure 3. 3.1.2. IP Address URIs This section provides the ABNF for IP version 4 and IP version 6 URIs. One application of this URI scheme is described in [I-D.ietf-geopriv-l7-lcp-ps], where an outbound SIP proxy needs to make location requests to a LIS on behalf of a Target because, for some reason, the necessary information was not provided by the Target. ip-uri = "ip:" ipv4 / ipv6 ipv4 = "IPv4+" IPv4address ; from RFC 3986 ipv6 = "IPv6+" IPv6address ; from RFC 3986 Winterbottom, et al. Expires May 7, 2009 [Page 6] Internet-Draft HELD Identity November 2008 The definitions for "IPv4address" and "IPv6address" are taken from [RFC3986]. An example of a location request including a URI in this form to identify the Target device is shown in Figure 1. geodetic ip:IPv4+192.0.2.5 Figure 1: HELD Location Request Using an IP Address Note that the URI types are not case sensitive and the iP:ipv4+ 192.0.2.5 is still a valid URI. 3.2. Schema This section defines a schema that is used to provide Target identifiers in a HELD location request. Winterbottom, et al. Expires May 7, 2009 [Page 7] Internet-Draft HELD Identity November 2008 Figure 2: Schema Winterbottom, et al. Expires May 7, 2009 [Page 8] Internet-Draft HELD Identity November 2008 The schema provided in Figure 2 allows a URI and/or token to be provided so that a Target can identify itself by more than just its IP address. The URI can also include an optional "type" attribute so that URIs that might otherwise look the same can be distinguished based on their usage. For example sip:callee@example.com or sip:callee@example.com An IANA registry is established for defining uri token types, and this defined in Section 6.4. When the element is used the "type" attribute is mandatory as it tells the LIS or receiving entity how to interpret the identifier. An IANA registry is established for the central repository for recognized identifier types. The set of initial types is provided in Section 6.3. A HELD location request sent by a device using the schema shown in Figure 2 to provide its identity as a MAC URI would look similar to Figure 3. geodetic mac:01-ab-34-ef-69-0c Figure 3: HELD Location Request URI example Similarly a Target identifying itself using its DHCP client identifier (DHCP option 61 in [RFC2132]) in a location request to a LIS would send something similar to Figure 4. geodetic 035552764 Figure 4: HELD Location Request Identifier example Winterbottom, et al. Expires May 7, 2009 [Page 9] Internet-Draft HELD Identity November 2008 4. Privacy Considerations A location configuration protocol has a very simple privacy model. Because the requester is also the Target, it can be assumed that providing that requester with location information is allowed. Such a policy makes the simple assumption that as the subject of the location information, the Target is also permitted access to that information. In effect, an LCP server (that is, the LIS) follows a single rule policy that states that the Target is the only authorized Location Recipient. Note: HELD explicitly takes the position that the Target is a Device and not a person. For the purpose of the discussion in this section, the two are considered one and the same. When the identity extensions defined above are used by the Target to augment an LCP query, this default "LCP policy" remains the relevant policy, and the security and privacy considerations of the base HELD protocol [I-D.ietf-geopriv-http-location-delivery] apply. The only augmentation required is that if the LCP policy is to be applied, the LIS MUST authenticate that the requested identity is in fact that of the requestor, and MUST deny access to location if this authentication fails. The LCP policy does not allow requests made by third parties. If a LIS permits requests from third parties using identity extensions, it assumes the rule of a Location Server (LS). HELD becomes a more general location request protocol--a "using protocol" by the definitions in [RFC3693]--and the privacy considerations for using protocols apply. As a Location Server, the LIS MUST explicitly authorize requests according to the policies that are provided by Rule Makers, including the Target. This includes authentication of requesters where required by the authorization policies. An organization that provides a LIS that allows third party requests SHOULD provide a means for a Rule Maker to specify authorization policies before allowing third party requests for that Target's location. Until an authorization policy is established, the LIS MUST reject requests by third parties. For a network operator, authorization might be a manual process, an explicit part of the terms of service for the network, or an automated system that accepts formal authorization policies (see [RFC4745], [RFC4825]). This document does not mandate any particular mechanism for establishing an authorization policy. When the LIS is operated by the Target's access network, the relationship between the Target and the LIS can be transient. Winterbottom, et al. Expires May 7, 2009 [Page 10] Internet-Draft HELD Identity November 2008 However, the process of establishing network access usually results in a form of agreement between the Target and the network provider. This process offers a natural vehicle for establishing location privacy policies. Winterbottom, et al. Expires May 7, 2009 [Page 11] Internet-Draft HELD Identity November 2008 5. Security Considerations The security considerations in [I-D.ietf-geopriv-http-location-delivery] describe the use of TLS for server authentication, confidentiality and protection from modification. These protections apply to both LCP requests and the requests made by third parties. 5.1. Location Configuration Protocol Requests Requests made by a Device (or Target) in the context of a location configuration protocol are covered by the same set of protections offered by HELD. All the security considerations for HELD apply. Identity information provided by the Device is private data that might be sensitive. The Device provides this information in the expectation that it assists the LIS in providing the Device a service. The LIS MUST NOT use identity information for any other purpose other than serving the request that includes that information. Falsification of identification information could be used by malicious Devices to gain access to location information for others, or to acquire false location information. For location configuration, the LIS MUST ensure that claimed identity information belongs to the requester before relying upon it. If this verification cannot be performed, the LIS MUST treat the request as if it were a third party request. Note: This might seem to negate much of the advantage provided by the inclusion of identity parameters for the LCP case. However, checking that the identity information is correct is generally more feasible than acquiring the information in the first place. For example, a MAC address provided by a target device can be verified by performing a DHCP lease-query ([RFC4388]). Identity extensions such as tel: URIs and hostnames can be validated using network services such as the DNS, ENUM, LDAP and SIP registrars. 5.2. Third Party Requests Requests from third parties have the same requirements for server authentication, confidentiality and protection from modification as LCP requests. However, because the third party needs to be authorized, the requester MUST be authenticated by the LIS. The LIS MUST NOT provide location information to unauthorized requesters. A LIS that allows requests from third parties MUST support TLS client Winterbottom, et al. Expires May 7, 2009 [Page 12] Internet-Draft HELD Identity November 2008 authentication. More detail on the privacy implications of third party requests are covered in Section 4. 5.3. Distinguishing LCP Requests from Third Party Requests There is a risk that a LIS that supports both LCP requests as well as requests from third parties could leak information. To successfully exploit this leak, a third party could convince the server that its request is an LCP request and that the identity information it provides indeed belongs to it. This could mean that the third party is exempted from the mandatory authorization process. A LIS that only provides LCP access to Targets is subject to the same attack. If a Target can provide false identification information that is accepted by the LIS, it can effectively act as an authorized third party. This is limited by the ability of the LIS to detect falsified identity information. Implementations need to take care to verify identity information as described in Section 5.1. For all requests, the LIS MUST ensure that the requester is authorized to receive location information for the specified Target before providing that information. Winterbottom, et al. Expires May 7, 2009 [Page 13] Internet-Draft HELD Identity November 2008 6. IANA Considerations This document registers an XML namespace and schema with IANA in accordance with guidelines in [RFC3688]. It also creates a new registry for device identity types, and stipulates how new types are to be added. 6.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held:id This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:held:id", as per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:ns:geopriv:held:id Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), James Winterbottom (james.winterbottom@andrew.com). XML: BEGIN HELD Device Identity Extensions

Namespace for HELD Device Identity Extensions

urn:ietf:params:xml:ns:geopriv:held:id

[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX with the RFC number for this specification.]]

See RFCXXXX.

END 6.2. XML Schema Registration This section registers an XML schema as per the guidelines in [RFC3688]. Winterbottom, et al. Expires May 7, 2009 [Page 14] Internet-Draft HELD Identity November 2008 URI: urn:ietf:params:xml:schema:geopriv:held:id Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), James Winterbottom (james.winterbottom@andrew.com). Schema: The XML for this schema can be found as the entirety of Figure 2 of this document. 6.3. Identifier 'type' Attribute values This document requests that the IANA create a new registry for identifier 'type' attribute values. These are text strings that clarify how the value identifies the Device. Referring to [RFC2434] this registry operates under the "Expert Review" rule. The following identifier types are registered as part of this memo: dhcpClientId: The DHCP client identifier as defined by DHCP option 61 in [RFC2132] msisdn: The Mobile Station International Subscriber Dial Number. This is an E.164 number made up of 6 to 15 digits imsi: The International Mobile Subscriber identifier. A unique identifier for GSM or UMTS mobile terminal made up of 6 to 15 digits that identify the country code, the network code and device. imei: The International Mobile Equipment identifier. This is an electronic serial number for a mobile device and is consists of up to 15 digits min: Mobile Identification Number. A unique equipment identifier assigned to CDMA handsets. mdn: Mobile Dial Number. An E.164 number made up of 6 to 15 digits. hostname: The hostname or FQDN of the device. directoryNumber: The directory number of the device. 6.4. URI Type Attribute Values This document requests that the IANA create a new registry for uri 'type' attribute values. These are text strings that clarify what a URI actually identifies, and MUSt include the URI scheme to which the type applies. Referring to [RFC2434] this registry operates under the "Expert Review" rule. Winterbottom, et al. Expires May 7, 2009 [Page 15] Internet-Draft HELD Identity November 2008 The following identifier types are registered as part of this memo: aor: The SIP address of record as defined [RFC3261]. Applies to 'sip:', 'sips:', 'pres:' gruu: The Globally Routable User Agent URI (GRUU) as defined in [I-D.ietf-sip-gruu]. Applies to 'sip:', 'sips:' Winterbottom, et al. Expires May 7, 2009 [Page 16] Internet-Draft HELD Identity November 2008 7. Acknowledgements The authors wish to thank the NENA VoIP location working group for their assistance in the definition of the schema used in this document. Special thanks go to Barbara Stark, Guy Caron, Nadine Abbott, Jerome Grenier and Martin Dawson. Thanks also to Bob Sherry for requesting that URI-types be supported which led to the typedURI form. Thanks to Adam Muhlbauer and Eddy Corbett for providing further corrections. Winterbottom, et al. Expires May 7, 2009 [Page 17] Internet-Draft HELD Identity November 2008 8. References 8.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [I-D.ietf-geopriv-http-location-delivery] Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, "HTTP Enabled Location Delivery (HELD)", draft-ietf-geopriv-http-location-delivery-10 (work in progress), October 2008. [I-D.ietf-geopriv-l7-lcp-ps] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in progress), June 2008. [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [I-D.ietf-sip-gruu] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-ietf-sip-gruu-15 (work in progress), October 2007. 8.2. Informative references [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. Winterbottom, et al. Expires May 7, 2009 [Page 18] Internet-Draft HELD Identity November 2008 [I-D.ietf-ecrit-phonebcp] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", draft-ietf-ecrit-phonebcp-05 (work in progress), July 2008. [I-D.thomson-geopriv-held-measurements] Thomson, M. and J. Winterbottom, "Using Device-provided Location-Related Measurements in Location Configuration Protocols", draft-thomson-geopriv-held-measurements-03 (work in progress), October 2008. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [LLDP] IEEE, "802.1AB, IEEE Standard for Local and Metropolitan area networks, Station and Media Access Control Connectivity Discovery", June 2005. [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006. [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol (DHCP) Leasequery", RFC 4388, February 2006. [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004. [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007. [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007. [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, November 2006. Winterbottom, et al. Expires May 7, 2009 [Page 19] Internet-Draft HELD Identity November 2008 Authors' Addresses James Winterbottom Andrew Corporation PO Box U40 University of Wollongong, NSW 2500 AU Email: james.winterbottom@andrew.com Martin Thomson Andrew Corporation PO Box U40 University of Wollongong, NSW 2500 AU Email: martin.thomson@andrew.com Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Phone: +358 (50) 4871445 Email: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at Richard Barnes BBN Technologies 9861 Broken Land Pkwy, Suite 400 Columbia, MD 21046 USA Phone: +1 410 290 6169 Email: rbarnes@bbn.com Winterbottom, et al. Expires May 7, 2009 [Page 20] Internet-Draft HELD Identity November 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Winterbottom, et al. Expires May 7, 2009 [Page 21]