idnits 2.17.1
draft-winterbottom-geopriv-held-identity-extensions-09.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** The document seems to lack a License Notice according IETF Trust
Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009
Section 6.b -- however, there's a paragraph with a matching beginning.
Boilerplate error?
(You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Feb 2009 rather than one of the newer Notices. See
https://trustee.ietf.org/license-info/.)
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Too long document name: The document name (without revision number),
'draft-winterbottom-geopriv-held-identity-extensions', is 51 characters
long, but may be at most 50 characters
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (February 25, 2009) is 5536 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Unused Reference: 'RFC4388' is defined on line 760, but no explicit
reference was found in the text
== Unused Reference: 'LLDP' is defined on line 807, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415)
** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542)
== Outdated reference: A later version (-16) exists of
draft-ietf-geopriv-http-location-delivery-12
== Outdated reference: A later version (-10) exists of
draft-ietf-geopriv-l7-lcp-ps-09
** Downref: Normative reference to an Informational draft:
draft-ietf-geopriv-l7-lcp-ps (ref. 'I-D.ietf-geopriv-l7-lcp-ps')
-- Obsolete informational reference (is this intentional?): RFC 3825
(Obsoleted by RFC 6225)
== Outdated reference: A later version (-20) exists of
draft-ietf-ecrit-phonebcp-07
== Outdated reference: A later version (-06) exists of
draft-thomson-geopriv-held-measurements-03
Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Geopriv J. Winterbottom
3 Internet-Draft M. Thomson
4 Intended status: Standards Track Andrew Corporation
5 Expires: August 29, 2009 H. Tschofenig
6 Nokia Siemens Networks
7 R. Barnes
8 BBN Technologies
9 February 25, 2009
11 Use of Target Identity in HTTP-Enabled Location Delivery (HELD)
12 draft-winterbottom-geopriv-held-identity-extensions-09
14 Status of This Memo
16 This Internet-Draft is submitted to IETF in full conformance with the
17 provisions of BCP 78 and BCP 79.
19 Internet-Drafts are working documents of the Internet Engineering
20 Task Force (IETF), its areas, and its working groups. Note that
21 other groups may also distribute working documents as Internet-
22 Drafts.
24 Internet-Drafts are draft documents valid for a maximum of six months
25 and may be updated, replaced, or obsoleted by other documents at any
26 time. It is inappropriate to use Internet-Drafts as reference
27 material or to cite them other than as "work in progress."
29 The list of current Internet-Drafts can be accessed at
30 http://www.ietf.org/ietf/1id-abstracts.txt.
32 The list of Internet-Draft Shadow Directories can be accessed at
33 http://www.ietf.org/shadow.html.
35 This Internet-Draft will expire on August 29, 2009.
37 Copyright Notice
39 Copyright (c) 2009 IETF Trust and the persons identified as the
40 document authors. All rights reserved.
42 This document is subject to BCP 78 and the IETF Trust's Legal
43 Provisions Relating to IETF Documents in effect on the date of
44 publication of this document (http://trustee.ietf.org/license-info).
45 Please review these documents carefully, as they describe your rights
46 and restrictions with respect to this document.
48 Abstract
50 When a Location Information Server receives a request for location
51 information (using the locationRequest message), described in the
52 base HTTP Enabled Location Delivery (HELD) specification, it uses the
53 source IP address of arriving message as a pointer to the location
54 determination process. This is sufficient in environments where a
55 Target's location can be determined based on its IP address.
57 Two additional use cases are addresses by this document. In the
58 first, location configuration requires additional or alternative
59 identifiers from the source IP address provided in the request. In
60 the second, an entity other than the Target requests the Target's
61 location.
63 This document extends the HELD protocol to allow the location request
64 message to carry Target identifiers. Privacy and security
65 considerations describe the conditions where requests containing
66 identifiers are permitted.
68 Table of Contents
70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
71 1.1. Applications . . . . . . . . . . . . . . . . . . . . . . . 4
72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
73 3. Target Identity . . . . . . . . . . . . . . . . . . . . . . . 5
74 3.1. Identifier Format and Protocol Details . . . . . . . . . . 6
75 3.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 7
76 3.2.1. IP Address . . . . . . . . . . . . . . . . . . . . . . 7
77 3.2.2. MAC Address . . . . . . . . . . . . . . . . . . . . . 7
78 3.2.3. TCP or UDP Port Number . . . . . . . . . . . . . . . . 8
79 3.2.4. Network Access Identifier . . . . . . . . . . . . . . 8
80 3.2.5. URI . . . . . . . . . . . . . . . . . . . . . . . . . 8
81 3.2.6. Hostname . . . . . . . . . . . . . . . . . . . . . . . 9
82 3.2.7. Directory Number . . . . . . . . . . . . . . . . . . . 9
83 3.2.8. Cellular Telephony Identifiers . . . . . . . . . . . . 9
84 3.2.9. DHCP Unique Identifier . . . . . . . . . . . . . . . . 10
85 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 10
86 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 12
87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
88 6.1. Location Configuration Protocol Requests . . . . . . . . . 14
89 6.2. Third Party Requests . . . . . . . . . . . . . . . . . . . 14
90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
91 7.1. URN Sub-Namespace Registration for
92 urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 14
93 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 15
94 7.3. Registration of HELD 'badIdentifier' Error Code . . . . . 15
95 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
96 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
97 9.1. Normative references . . . . . . . . . . . . . . . . . . . 16
98 9.2. Informative references . . . . . . . . . . . . . . . . . . 17
100 1. Introduction
102 Protocols for requesting and providing location information require a
103 way for the requestor to specify the location that should be
104 returned. In a location configuration protocol (LCP), the location
105 being requested is the requestor's location. This fact can make the
106 problem of identifying the Device simpler for LCPs, since IP
107 datagrams that carry the request already carry an identifier for the
108 Device, namely the source IP address of an incoming request.
109 Existing LCPs, such as HELD [I-D.ietf-geopriv-http-location-delivery]
110 and DHCP ([RFC3825], [RFC4776]) rely on the source IP address, and
111 possibly lower-layer identifiers to identify a Device.
113 Aside from the datagrams that form a request, a location information
114 server (LIS) does not necessarily have access to information that
115 could further identify the Target. In some circumstances, as shown
116 in [I-D.ietf-geopriv-l7-lcp-ps], additional identification
117 information can be included in a request to identify a Target.
119 This document extends the HELD protocol to support the inclusion of
120 additional identifiers for the Target in HELD location requests. An
121 XML schema is defined that provides a structure for including these
122 identifiers in HELD requests.
124 An important characteristic of this addition to the HELD protocol is
125 that is also expands the potential scope of HELD beyond that of an
126 LCP. The scope of an LCP is limited to the interaction between a
127 Device and a LIS. That is, an LCP is limited to the Device
128 retrieving information about their own location. With this addition,
129 third party location recipients (LRs) are able to make requests that
130 include identifiers to retrieve location information about a
131 particular Target.
133 The usage of HELD for purposes beyond the Device-LIS interaction
134 obviously introduces a new set of privacy concerns. In an LCP, the
135 requester is implicitly authorized to access the requested location
136 information, because it is their own location. In contrast, when a
137 third party LR requests a Target's location, the LR MUST be
138 explicitly authorized. Establishing appropriate authorization and
139 other related privacy concerns are discussed in Section 5.
141 1.1. Applications
143 The use of additional identifiers in HELD falls into two categories.
144 A Device can use these parameters to provide additional
145 identification information to a LIS. Identification such as the
146 hardware address of the Device can be used to reduce the time
147 required to determine the location of the Device. In other cases, a
148 LIS might require Device identification before any location
149 information can be generated.
151 A third party LR can be granted authorization to make requests for a
152 given Target. In particular, network services can be permitted to
153 retrieve location for a Device that is unable to acquire location
154 information for itself (see Section 6.3 of
155 [I-D.ietf-ecrit-phonebcp]). This allows use of location-dependent
156 applications--particularly essential services like emergency
157 calling--where Devices do not support a location configuration
158 protocol (LCP) or they are unable to successfully retrieve location
159 information.
161 2. Terminology
163 This document uses the term Location Information Server (LIS) and
164 location configuration protocol (LCP) as described in
165 [I-D.ietf-geopriv-l7-lcp-ps].
167 This document reuses the term Target to refer to the subject of any
168 request for location information. The term Device is used
169 specifically as the subject of an LCP, consistent with
170 [I-D.ietf-geopriv-http-location-delivery]. Both these terms are
171 defined in [RFC3693].
173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
175 document are to be interpreted as described in [RFC2119].
177 3. Target Identity
179 Identifiers are used as the starting point in location determination.
180 They should not be confused with measurement information
181 ([I-D.thomson-geopriv-held-measurements]). Measurement information
182 is information about a Device and the time varying details of its
183 network attachment. Identifiers might be associated with a different
184 Target over time, but the their purpose is to identify the Target,
185 not to describe its environment or network attachment.
187 Use of any identifier MUST only be allowed if it uniquely identifies
188 a single Target. In some circumstances, certain of these identifiers
189 are either temporary or could potentially identify multiple devices.
190 Identifiers that are transient or ambiguous could be exploited by an
191 attacker to either gain information about another device or to obtain
192 misleading information.
194 The identifiers described in this section SHOULD only be used where
195 that identifier is used as the basis for location determination. It
196 is tempting for a LIS implementation to allow alternative identifiers
197 for convenience or some other perceived benefit. However, care needs
198 to be taken to ensure that the binding between the indicated
199 identifier and the identifier that is used for location determination
200 is unique and not subject to attacks.
202 3.1. Identifier Format and Protocol Details
204 XML elements are used to express the Target identity. The "target"
205 element is used as a general container for identity information.
206 This document defines a basic set of identifiers. An example HELD
207 request, shown in Figure 1, includes an IP version 4 address.
209
See RFCXXXX.
638 639 640 END 642 7.2. XML Schema Registration 644 This section registers an XML schema as per the guidelines in 645 [RFC3688]. 647 URI: urn:ietf:params:xml:schema:geopriv:held:id 649 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 650 James Winterbottom (james.winterbottom@andrew.com). 652 Schema: The XML for this schema can be found as the entirety of 653 Section 4 of this document. 655 7.3. Registration of HELD 'badIdentifier' Error Code 657 This section registers the "badIdentifier" error code in the "Geopriv 658 HELD Registries, Error codes for HELD" IANA registry. 660 badIdentifier This error code indicates that the Target identifiers 661 used in the HELD request were either: not supported by the LIS, 662 badly formatted, or that the requester was not authorized to make 663 a erquest for that identifier. 665 8. Acknowledgements 667 The authors wish to thank the NENA VoIP location working group for 668 their assistance in the definition of the schema used in this 669 document. Special thanks go to Barbara Stark, Guy Caron, Nadine 670 Abbott, Jerome Grenier and Martin Dawson. Bob Sherry provided input 671 on use of URIs. Thanks to Adam Muhlbauer and Eddy Corbett for 672 providing further corrections. Bernard Aboba provided extensive 673 feedback on use cases and the security model; Bernard, along with 674 Alan DeKok, also helped resolve an issue with NAIs. Ray Bellis 675 provided motivation for the protocol port parameters. 677 9. References 679 9.1. Normative references 681 [RFC2119] Bradner, S., "Key words 682 for use in RFCs to 683 Indicate Requirement 684 Levels", BCP 14, RFC 2119, 685 March 1997. 687 [RFC3315] Droms, R., Bound, J., 688 Volz, B., Lemon, T., 689 Perkins, C., and M. 690 Carney, "Dynamic Host 691 Configuration Protocol for 692 IPv6 (DHCPv6)", RFC 3315, 693 July 2003. 695 [RFC3688] Mealling, M., "The IETF 696 XML Registry", BCP 81, 697 RFC 3688, January 2004. 699 [RFC4282] Aboba, B., Beadles, M., 700 Arkko, J., and P. Eronen, 701 "The Network Access 702 Identifier", RFC 4282, 703 December 2005. 705 [RFC4361] Lemon, T. and B. 706 Sommerfeld, "Node-specific 707 Client Identifiers for 708 Dynamic Host Configuration 709 Protocol Version Four 710 (DHCPv4)", RFC 4361, 711 February 2006. 713 [I-D.ietf-geopriv-http-location-delivery] Barnes, M., Winterbottom, 714 J., Thomson, M., and B. 715 Stark, "HTTP Enabled 716 Location Delivery (HELD)", 717 draft-ietf-geopriv-http- 718 location-delivery-12 (work 719 in progress), 720 January 2009. 722 [I-D.ietf-geopriv-l7-lcp-ps] Tschofenig, H. and H. 723 Schulzrinne, "GEOPRIV 724 Layer 7 Location 725 Configuration Protocol; 726 Problem Statement and 727 Requirements", draft-ietf- 728 geopriv-l7-lcp-ps-09 (work 729 in progress), 730 February 2009. 732 [W3C.REC-xml-names11-20060816] Tobin, R., Layman, A., 733 Bray, T., and D. 734 Hollander, "Namespaces in 735 XML 1.1 (Second Edition)", 736 World Wide Web Consortium 737 Recommendation REC-xml- 738 names11-20060816, 739 August 2006,