idnits 2.17.1
draft-ietf-geopriv-deref-protocol-07.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
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 date (July 14, 2012) is 4304 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: 'RFC3986' is defined on line 610, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110)
** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525)
== Outdated reference: A later version (-19) exists of
draft-ietf-geopriv-dhcp-lbyr-uri-option-15
== Outdated reference: A later version (-27) exists of
draft-ietf-geopriv-policy-26
== Outdated reference: A later version (-07) exists of
draft-ietf-geopriv-policy-uri-04
-- Obsolete informational reference (is this intentional?): RFC 5246
(Obsoleted by RFC 8446)
-- Obsolete informational reference (is this intentional?): RFC 5751
(Obsoleted by RFC 8551)
Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 GEOPRIV J. Winterbottom
3 Internet-Draft Commscope
4 Intended status: Standards Track H. Tschofenig
5 Expires: January 15, 2013 Nokia Siemens Networks
6 H. Schulzrinne
7 Columbia University
8 M. Thomson
9 Microsoft
10 July 14, 2012
12 A Location Dereferencing Protocol Using HELD
13 draft-ietf-geopriv-deref-protocol-07
15 Abstract
17 This document describes how to use the Hypertext Transfer Protocol
18 (HTTP) over Transport Layer Security (TLS) as a dereferencing
19 protocol to resolve a reference to a Presence Information Data Format
20 Location Object (PIDF-LO). The document assumes that a Location
21 Recipient possesses a URI that can be used in conjunction with the
22 HTTP-Enabled Location Delivery (HELD) protocol to request the
23 location of the Target.
25 Status of this Memo
27 This Internet-Draft is submitted in full conformance with the
28 provisions of BCP 78 and BCP 79.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF). Note that other groups may also distribute
32 working documents as Internet-Drafts. The list of current Internet-
33 Drafts is at http://datatracker.ietf.org/drafts/current/.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as "work in progress."
40 This Internet-Draft will expire on January 15, 2013.
42 Copyright Notice
44 Copyright (c) 2012 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (http://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with respect
52 to this document. Code Components extracted from this document must
53 include Simplified BSD License text as described in Section 4.e of
54 the Trust Legal Provisions and are provided without warranty as
55 described in the Simplified BSD License.
57 Table of Contents
59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
61 3. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 4
62 3.1. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 4
63 3.2. HTTP GET Behavior . . . . . . . . . . . . . . . . . . . . 5
64 4. Authorization Models . . . . . . . . . . . . . . . . . . . . . 6
65 4.1. Authorization by Possession . . . . . . . . . . . . . . . 7
66 4.2. Authorization via Access Control . . . . . . . . . . . . . 8
67 4.3. Access Control with HELD Deference . . . . . . . . . . . . 8
68 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
74 9.2. Informative references . . . . . . . . . . . . . . . . . . 15
75 Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 16
76 Appendix B. Compliance to Location Reference Requirements . . . . 19
77 B.1. Requirements for a Location Configuration Protocol . . . . 20
78 B.2. Requirements for a Location Dereference Protocol . . . . . 21
79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
81 1. Introduction
83 A location URI [RFC5808] identifies a resource that contains the
84 location of an entity. This document specifies how a holder of an
85 "http:" or "https:" location URI uses that URI to retrieve location
86 information.
88 A location URI can be acquired using a location configuration
89 protocol, such as HTTP-Enabled Location Delivery (HELD) [RFC5985] or
90 the Dynamic Host Configuration Protocol (DHCP) location URI option
91 [I-D.ietf-geopriv-dhcp-lbyr-uri-option].
93 A Location Recipient that dereferences a location URI acquires
94 location information in the of a Presence Information Data Format -
95 Location Object (PIDF-LO) document [RFC4119]. HELD parameters allow
96 for specifying the type of location information, though some
97 constraints are placed on allowable parameters.
99 Location URIs compatible with HELD dereferencing use the "https:" or
100 "http:" scheme. HELD can be used by Location Recipients that are
101 aware of the fact that the URI is a location URI. Mandatory support
102 for an HTTP GET request ensures that the URI can be used even if it
103 is not recognized as a location URI.
105 2. Terminology
107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
109 document are to be interpreted as described in [RFC2119].
111 This document uses key terminology from several sources:
113 o terms for the GEOPRIV reference model defined in [RFC6280];
115 o the term Location Information Server (LIS), from [RFC5687], is a
116 node in the access network that provides location information to
117 an end point; a LIS provides location URIs;
119 o the term Location Server (LS), from [RFC6280], is used to identify
120 the role that responds to a location dereference request; this
121 might be the same entity as the LIS, but the model in [RFC5808]
122 allows for the existence of separate - but related - entities; and
124 o the term location URI is coined in [RFC5808].
126 3. HELD Dereference Protocol
128 This section describes how HELD can be used to dereference a location
129 URI. This process can be applied when a Location Recipient is in
130 possession of a location URI with a "https:" or "http:" URI scheme.
132 This document does not describe a specific authentication mechanism.
133 This means that authorization policies are unable to specifically
134 identify authorized Location Recipients.
136 A Location Recipient that wishes to dereference an "https:" or
137 "http:" URI performs a HELD request on HTTP to the identified
138 resource.
140 Note: In many cases, an "http:" URI does not provide sufficient
141 security for location URIs. The absence of the security
142 mechanisms provided by TLS means that the Rule Maker has no
143 control over who receives location information and the Location
144 Recipient has no assurance that the information is correct.
146 The Location Recipient establishes a connection to the LS, as
147 described in [RFC2818].
149 The scheme of a location URI determines whether or not TLS is used on
150 a given dereference transaction. Location Servers MUST be configured
151 to issue only HTTPS URIs and respond to only to HTTPS dereference
152 requests, unless confidentiality and integrity protection are
153 provided by some other mechanism. For example, the server might only
154 accept requests from clients within a trusted network, or via an
155 IPsec-protected channel. When TLS is used, the TLS ciphersuite
156 TLS_NULL_WITH_NULL_NULL MUST NOT be used and the LS MUST be
157 authenticated [RFC6125] to ensure that the correct server is
158 contacted.
160 A Location Server MAY reject a request and request that a Location
161 Recipient provide authentication credentials if authorization is
162 dependent on the Location Recipient identity. Future specifications
163 could define an authentication mechanism and a means by which
164 Location Recipients are identified in authorization policies. This
165 document provides definitions for neither item.
167 3.1. HELD Usage Profile
169 Use of HELD as a location dereference protocol is largely the same as
170 its use as a location configuration protocol. Aside from the
171 restrictions noted in this document, HELD semantics do not differ
172 from those established in [RFC5985].
174 The HELD "locationRequest" is the only request permitted by this
175 specification. Similarly, request parameters other than the
176 following MUST NOT be accepted by the LS: "responseTime",
177 "locationType" (including the associated "exact" attribute).
179 Parameters and requests that do not have known behaviour for
180 dereference requests MUST NOT be used. The LS MUST ignore any
181 parameters that it does not understand unless it knows the parameters
182 to be invalid. If parameters are understood by the LS and known to
183 be invalid, the LS MAY generate a HELD error response. For instance,
184 those defined in [RFC6155] are always invalid and can be rejected.
186 The LS MUST NOT generate location URIs or provide a "locationUriSet"
187 in response to a dereference request. If the location request
188 contains a "locationType" element that includes "locationURI", this
189 parameter is either ignored or rejected as appropriate, based on the
190 associated "exact" attribute.
192 3.2. HTTP GET Behavior
194 GET is the method assumed by generic HTTP user agents, therefore
195 unless context identifies an "https:" URI as a HELD URI, such a user
196 agent might simply send an HTTP GET. Rather than providing an HTTP
197 405 (Method Not Allowed) response indicating that POST is the only
198 permitted method, a LIS MUST provide a HELD location response if it
199 receives an HTTP GET request.
201 An HTTP GET request to a HELD URI produces a HELD response as if the
202 following HELD request had been sent using HTTP POST:
204
205
206 geodetic civic
207
208
210 Figure 1: GET Request Equivalent Location Request
212 HTTP GET requests MUST be safe and idempotent [RFC2616] - that is,
213 there are no side-effects of making the request and a repeated
214 request has no more effect than a single request. Repeating a HELD
215 request might result in a different location, but only as a result of
216 a change in the state of the resource: the location of the Target.
218 Only the creation of a location URI as a result of receiving a
219 request causes a HELD request to have side-effects. A request to a
220 location URI can be both safe and idempotent, since a location URI
221 cannot be produced in response to a request to a location URI.
223 A Location Recipient MAY infer from a response containing the HELD
224 content type, "application/held+xml", that a URI references a
225 resource that supports HELD.
227 Content negotiation MAY be supported to produce a presence document
228 in place of a HELD location response. Where the presence document
229 would otherwise be included in a "locationResponse" document, it can
230 be included in the body of the HTTP response directly by including an
231 "Accept" header that includes "application/pidf+xml".
233 4. Authorization Models
235 This section discusses two extreme types of authorization models for
236 dereferencing with HELD URIs, namely "Authorization by Possession"
237 and "Authorization by Access Control". In the subsequent subsections
238 we discuss the properties of these two models. Figure 2, from
239 [RFC5808], shows the model applicable to location configuration,
240 conveyance and dereference.
242 +---------+--------+ Location +-----------+
243 | | | Dereference | Location |
244 | LIS - LS +---------------+ Recipient |
245 | | | Protocol | |
246 +----+----+--------+ (3) +-----+-----+
247 | `. |
248 | Policy `. |
249 Location | Exchange `. |
250 Configuration | (*) | |
251 Protocol | +----+----+ |
252 (1) | | Rule | Location |
253 | | Maker | Conveyance |
254 +-----+----+ +---------+ Protocol |
255 | | (2) |
256 | Target +------------------------------+
257 | |
258 +----------+
260 Figure 2: Communication Model
262 It is important to note that this document does not mandate a
263 specific authorization model. It is possible to combine aspects of
264 both models. However, no authentication framework is provided, which
265 limits the policy options available when the "Authorization by Access
266 Control" model is used.
268 For either authorization model, the overall process is similar. The
269 following steps are followed, with minor alterations:
271 1. The Target acquires a location URI from the LIS. This uses a
272 location configuration protocol (LCP), such as HELD or DHCP.
274 2. The Target then conveys the location URI to a third party, the
275 Location Recipient (for example using SIP as described in
276 [RFC6442]). This step is shown in (2) of Figure 2.
278 3. The Location Recipient then needs to dereference the location URI
279 in order to obtain the Location Object (3). An "https:" or
280 "http:" URI is dereferenced as described in this document; other
281 URI schemes might be dereferenced using another method.
283 In this final step, the Location Server (LS) or LIS makes an
284 authorization decision. How this decision is reached depends on the
285 authorization model.
287 4.1. Authorization by Possession
289 In this model, possession - or knowledge - of the location URI is
290 used to control access to location information. A location URI might
291 be constructed such that it is hard to guess (see C8 of [RFC5808])
292 and the set of entities that it is disclosed to can be limited. The
293 only authentication this would require by the LS is evidence of
294 possession of the URI. The LS could immediately authorize any
295 request that indicates this URI.
297 Authorization by possession does not require direct interaction with
298 a Rule Maker; it is assumed that the Rule Maker is able to exert
299 control over the distribution of the location URI. Therefore, the
300 LIS can operate with limited policy input from a Rule Maker.
302 Limited disclosure is an important aspect of this authorization
303 model. The location URI is a secret; therefore, ensuring that
304 adversaries are not able to acquire this information is paramount.
305 Encryption, such as might be offered by TLS [RFC5246] or S/MIME
306 [RFC5751], protects the information from eavesdroppers.
308 Use of authorization by possession location URIs in a hop-by-hop
309 protocol such as SIP [RFC3261] adds the possibility of on-path
310 adversaries. Depending on the usage of the location URI for certain
311 location based applications (e.g., emergency services, location based
312 routing) specific treatment is important, as discussed in [RFC6442].
314 Using possession as a basis for authorization means that, once
315 granted, authorization cannot be easily revoked. Cancellation of a
316 location URI ensures that legitimate users are also affected;
317 application of additional policy is theoretically possible, but could
318 be technically infeasible. Expiration of location URIs limits the
319 usable time for a location URI, requiring that an attacker continue
320 to learn new location URIs to retain access to current location
321 information.
323 A very simple policy might be established at the time that a location
324 URI is created. This policy specifies that the location URI expires
325 after a certain time, which limits any inadvertent exposure of
326 location information to adversaries. The expiration time of the
327 location URI might be negotiated at the time of its creation, or it
328 might be unilaterally set by the LIS.
330 4.2. Authorization via Access Control
332 Use of explicit access control provides a Rule Maker greater control
333 over the behaviour of an LS. In contrast to authorization by
334 possession, possession of this form of location URI does not imply
335 authorization. Since an explicit policy is used to authorize access
336 to location information, the location URI can be distributed to many
337 potential Location Recipients.
339 Either before creation or dissemination of the location URI, the Rule
340 Maker establishes an authorization policy with the LS. In reference
341 to Figure 2, authorization policies might be established at creation
342 (Step 1), and need to be established before the location URI is
343 published (Step 2) to ensure that the policy grants access to the
344 desired Location Recipients. Depending on the mechanism used, it
345 might also be possible to change authorization policies at any time.
347 A possible format for these authorization policies is available with
348 GEOPRIV Common Policy [RFC4745] and Geolocation Policy
349 [I-D.ietf-geopriv-policy]. Additional constraints might be
350 established by other means.
352 The LS enforces the authorization policy when a Location Recipient
353 dereferences the URI. Explicit authorization policies allow a Rule
354 Maker to specify how location information is provided to Location
355 Recipients.
357 4.3. Access Control with HELD Deference
359 This document does not describe a specific authentication mechanism;
360 therefore, the authorization by access control model is not an
361 option. Instead, this document assumes the authorization by
362 possession model.
364 Other policy mechanisms, such as those described in
365 [I-D.ietf-geopriv-policy], can be applied for different Location
366 Recipients if each recipient is given a different location URIs.
368 Each location URI can be assigned different authorization policy.
369 Selective disclosure used in this fashion can be used in place of
370 identity-based authorization.
372 How policy is associated with a location URI is not defined by this
373 document. [I-D.ietf-geopriv-policy-uri] describes one possible
374 mechanism.
376 Use of identity-based authorization policy is not precluded. A
377 Location Server MAY support an authentication mechanism that enables
378 identity-based authorization policies to be used. Future
379 specifications might define means of identifying recipients.
381 Note: Policy frameworks like [RFC4745] degrade in a way that
382 protects privacy if features are not supported. If a policy
383 specifies a rule that is conditional on the identity of a
384 recipient and the protocol does not (or cannot) provide an
385 assertion identity of the recipient, the rule has no effect and
386 the policy defaults to providing less information.
388 5. Examples
390 An example scenario envisioned by this document is shown in Figure 3.
391 This diagram shows how a location dereference protocol fits with
392 location configuration and conveyance. [RFC5808] contains more
393 information on this scenario and others like it.
395 +-------------+
396 +------------+ | Location | +-----------+
397 | End Device | | Information | | Location |
398 | (Target) | | Server | | Recipient |
399 +-----+------+ +------+------+ +-----+-----+
400 | | |
401 .- + - - - - - - - - - - - - + -. |
402 : | locationRequest | : |
403 . |----(for location URI)-->| . |
404 : | | : Location |
405 . | locationResponse | . Configuration |
406 : |<-----(location URI)-----| : |
407 . | | . |
408 `- + - - - - - - - - - - - - + -' |
409 | | |
410 | Location Conveyance |
411 |~ ~ ~ ~ ~ ~ ~ ~ ~ ~(location URI)~ ~ ~ ~ ~ ~ ~ ~ ~>|
412 | | |
413 | .- + - - - - - - - - - - - - + -.
414 | : | locationRequest | :
415 | . |<------(for civic)-------| .
416 | Dereferencing : | | :
417 | . | locationResponse | .
418 | : |--------(PIDF-LO)------->| :
419 | . | | .
420 | `- + - - - - - - - - - - - - + -'
421 | | |
423 Figure 3: Example of Dereference Protocol Exchange
425 The example in Figure 4 shows the simplest form of dereferencing
426 request using HELD to the location URI
427 "https://ls.example.com:49152/uri/w3g61nf5n66p0". The only way that
428 this differs from the example in Section 10.1 of [RFC5985] is in the
429 request URI and the source of the URI.
431 POST /uri/w3g61nf5n66p0 HTTP/1.1
432 Host: ls.example.com:49152
433 Content-Type: application/held+xml
434 Content-Length: 87
436
437
439 Figure 4: Minimal Dereferencing Request
441 Figure 5 shows the response to the previous request listing both
442 civic and geodetic location information of the Target's location.
444 Again, this is identical to the response in Section 10.1 of [RFC5985]
445 - unless policy specifies otherwise, the Location Recipient receives
446 the same information as the Device.
448 HTTP/1.1 200 OK
449 Server: Example LIS
450 Date: Mon, 10 Jan 2011 03:42:29 GMT
451 Expires: Tue, 11 Jan 2011 03:42:29 GMT
452 Cache-control: private
453 Content-Type: application/held+xml
454 Content-Length: 676
456
457
458
460
461
462
464
465
467 -34.407 150.88001
468
469
470
471
472 false
473
474 2011-01-11T03:42:29+00:00
475
476 Wiremap
477
478
479 2006-01-10T03:42:28+00:00
480
481
482
484 Figure 5: Response with Location Information
486 The following GET request is treated in an equivalent fashion. The
487 LS treats this request as though it were a location request of the
488 form shown in Figure 1. The same response might be provided.
490 GET /uri/w3g61nf5n66p0 HTTP/1.1
491 Host: ls.example.com:49152
492 Accept: application/held+xml
494 Figure 6: GET Request
496 The following GET request uses content negotiation to indicate a
497 preference for a presence document.
499 GET /uri/w3g61nf5n66p0 HTTP/1.1
500 Host: ls.example.com:49152
501 Accept: application/pidf+xml,application/held+xml;q=0.5
503 Figure 7: GET Request with Content Negotiation
505 The response only differs from a normal HELD location response to a
506 POST request in that the "locationResponse" element is omitted and
507 the "Content-Type" header reflects the changed content.
509 HTTP/1.1 200 OK
510 Server: Example LIS
511 Date: Mon, 10 Jan 2011 03:42:29 GMT
512 Expires: Tue, 11 Jan 2011 03:42:29 GMT
513 Cache-control: private
514 Content-Type: application/pidf+xml
515 Content-Length: 591
517
518
520
521
523 Figure 8: GET Response with PIDF-LO
525 6. Security Considerations
527 Privacy of location information is the most important security
528 consideration for this document. Two measures in particular are used
529 to protect privacy: TLS and authorization policies. TLS provides a
530 means of ensuring confidentiality of location information through
531 encryption and mutual authentication. An authorization policy allows
532 a Rule Maker to explicitly control how location information is
533 provided to Location Recipients.
535 The process by which a Rule Maker establishes an authorization policy
536 is not covered by this document; several methods are possible, for
537 instance: [I-D.ietf-geopriv-policy-uri], [RFC4825].
539 TLS MUST be used for dereferencing location URIs unless
540 confidentiality and integrity are provided by some other mechanism,
541 as discussed in Section 3. Location Recipients MUST authenticate the
542 host identity using the domain name included in the location URI,
543 using the procedure described in Section 3.1 of [RFC2818]. Local
544 policy determines what a Location Recipient does if authentication
545 fails or cannot be attempted.
547 The authorization by possession model (Section 4.1) further relies on
548 TLS when transmitting the location URI to protect the secrecy of the
549 URI. Possession of such a URI implies the same privacy
550 considerations as possession of the PIDF-LO document that the URI
551 references.
553 Location URIs MUST only be disclosed to authorized Location
554 Recipients. The GEOPRIV architecture [RFC6280] identifies the Rule
555 Maker role as being the entity that authorizes disclosure of this
556 nature.
558 Protection of the location URI is necessary, since the policy
559 attached to such a location URI permits any who have the URI to view
560 it. This aspect of security is covered in more detail in the
561 specification of location conveyance protocols, such as [RFC6442].
563 The LS MUST NOT provide any information about the Target except its
564 location, unless policy from a Rule Maker allows otherwise. In
565 particular, the requirements in [RFC5808] mandate this measure to
566 protect the identity of the Target. To this end, an unlinked
567 pseudonym MUST be provided in the "entity" attribute of the PIDF-LO
568 document.
570 Further security considerations and requirements relating to the use
571 of location URIs are described in [RFC5808].
573 7. IANA Considerations
575 This document makes no request of IANA.
577 [[IANA/RFC-EDITOR: Please remove this section before publication.]]
579 8. Acknowledgements
581 Thanks to Barbara Stark and Guy Caron for providing early comments.
582 Thanks to Rohan Mahy for constructive comments on the scope and
583 format of the document. Thanks to Ted Hardie for his strawman
584 proposal that provided assistance with the security section of this
585 document. Richard Barnes made helpful observations on the
586 application of authorization policy. Bernard Aboba and Julian
587 Reschke contributed constructive reviews.
589 The participants of the GEOPRIV interim meeting 2008 provided
590 significant feedback on this document.
592 James Polk provided input on security in June 2008.
594 Martin Dawson was an original author of this document. Sadly, he
595 passed away prior to its publication.
597 9. References
599 9.1. Normative References
601 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
602 Requirement Levels", BCP 14, RFC 2119, March 1997.
604 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
605 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
606 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
608 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
610 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
611 Resource Identifier (URI): Generic Syntax", STD 66,
612 RFC 3986, January 2005.
614 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
615 Format", RFC 4119, December 2005.
617 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
618 Presence Information Data Format Location Object (PIDF-LO)
619 Usage Clarification, Considerations, and Recommendations",
620 RFC 5491, March 2009.
622 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
623 RFC 5985, September 2010.
625 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
626 Verification of Domain-Based Application Service Identity
627 within Internet Public Key Infrastructure Using X.509
628 (PKIX) Certificates in the Context of Transport Layer
629 Security (TLS)", RFC 6125, March 2011.
631 9.2. Informative references
633 [I-D.ietf-geopriv-dhcp-lbyr-uri-option]
634 Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4
635 and IPv6 Option for a Location Uniform Resource Identifier
636 (URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-15 (work
637 in progress), May 2012.
639 [I-D.ietf-geopriv-policy]
640 Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J.,
641 Morris, J., and M. Thomson, "Geolocation Policy: A
642 Document Format for Expressing Privacy Preferences for
643 Location Information", draft-ietf-geopriv-policy-26 (work
644 in progress), June 2012.
646 [I-D.ietf-geopriv-policy-uri]
647 Thomson, M., Winterbottom, J., Barnes, R., and H.
648 Tschofenig, "Location Configuration Extensions for Policy
649 Management", draft-ietf-geopriv-policy-uri-04 (work in
650 progress), November 2011.
652 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
653 A., Peterson, J., Sparks, R., Handley, M., and E.
654 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
655 June 2002.
657 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
658 J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
660 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
661 Polk, J., and J. Rosenberg, "Common Policy: A Document
662 Format for Expressing Privacy Preferences", RFC 4745,
663 February 2007.
665 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
666 Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
668 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
669 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
671 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
672 Location Configuration Protocol: Problem Statement and
673 Requirements", RFC 5687, March 2010.
675 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
676 Mail Extensions (S/MIME) Version 3.2 Message
677 Specification", RFC 5751, January 2010.
679 [RFC5808] Marshall, R., "Requirements for a Location-by-Reference
680 Mechanism", RFC 5808, May 2010.
682 [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R.
683 Barnes, "Use of Device Identity in HTTP-Enabled Location
684 Delivery (HELD)", RFC 6155, March 2011.
686 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
687 Tschofenig, H., and H. Schulzrinne, "An Architecture for
688 Location and Location Privacy in Internet Applications",
689 BCP 160, RFC 6280, July 2011.
691 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
692 for the Session Initiation Protocol", RFC 6442,
693 December 2011.
695 Appendix A. GEOPRIV Using Protocol Compliance
697 This section describes how use of HELD as a location dereference
698 protocol complies with the GEOPRIV requirements described in
699 [RFC3693].
701 Req. 1. (Location Object generalities):
703 This section relates to the PIDF-LO [RFC4119] document,
704 which is used by HELD. These requirements are addressed by
705 [RFC4119] and [RFC5491].
707 Req. 2. (Location Object fields):
709 This section relates to the PIDF-LO [RFC4119] document,
710 which is used by HELD. These requirements are addressed by
711 [RFC4119] and [RFC5491].
713 Req. 3. (Location Data Types):
715 This section relates to the PIDF-LO [RFC4119] document,
716 which is used by HELD. These requirements are addressed by
717 [RFC4119] and [RFC5491].
719 Section 7.2 of [RFC3693] details the requirements of a "Using
720 Protocol". These requirements are restated, followed by a statement
721 of compliance:
723 Req. 4. "The using protocol has to obey the privacy and security
724 instructions coded in the Location Object and in the
725 corresponding Rules regarding the transmission and storage
726 of the LO."
728 Compliant: This specification describes the use of HTTP over
729 TLS for carring the PIDF-LO from the LS to the Location
730 Recipient. The sending and receiving parties are expected
731 to comply with the instructions carried inside the object.
733 Though discouraged, using unsecured http: URIs is permitted.
734 Using unsecured HTTP is likely to result in non-compliance
735 with this requirement.
737 Req. 5. "The using protocol will typically facilitate that the keys
738 associated with the credentials are transported to the
739 respective parties, that is, key establishment is the
740 responsibility of the using protocol."
742 Compliant: This document specifies that authentication of
743 the LS uses the established public key infrastructure used
744 by HTTP over TLS [RFC2818]. Authentication of Location
745 Recipients is either based on distribution of a secret (the
746 location URI) using a conveyance protocol (for instance,
747 [RFC6442]), allowances are made for later work to define
748 alternative methods.
750 Req. 6. "(Single Message Transfer) In particular, for tracking of
751 small target devices, the design should allow a single
752 message/packet transmission of location as a complete
753 transaction."
755 Not Compliant: The XML encoding specified in [RFC4119] is
756 not suited to single packet transfers. Use of compressed
757 content encoding [RFC2616] might allow this condition to be
758 met.
760 Section 7.3 of [RFC3693] details the requirements of a "Rule based
761 Location Data Transfer". These requirements are restated where they
762 are applicable to this document:
764 Req. 7. "(LS Rules) The decision of a Location Server to provide a
765 Location Recipient access to Location Information MUST be
766 based on Rule Maker-defined Privacy Rules."
768 Compliant: This document describes two alternative methods
769 by which a Rule Maker is able to control access to location
770 information. Rule Maker policy is enforced by the LS when
771 a location URI is dereferenced. However, this document
772 does not describe how a location URI is created, or how a
773 Rule Maker associates policy with a location URI. These
774 are covered by other specifications.
776 Req. 8. (LG Rules) Not Applicable: This relationship between LS and
777 the source of its information (be that Location Generator
778 (LG) or LIS) is out of scope for this document.
780 Req. 9. "(Viewer Rules) A Viewer does not need to be aware of the
781 full Rules defined by the Rule Maker (because a Viewer
782 SHOULD NOT retransmit Location Information), and thus a
783 Viewer SHOULD receive only the subset of Privacy Rules
784 necessary for the Viewer to handle the LO in compliance
785 with the full Privacy Rules (such as, instruction on the
786 time period for which the LO can be retained)."
788 Compliant: The Rule Maker might define (via mechanisms
789 outside the scope of this document) which policy rules are
790 disclosed to other entities. For instance, if [RFC4745] is
791 used to convey authorization policies from Rule Maker to
792 LS, this is possible using the parameters specified in
793 [I-D.ietf-geopriv-policy].
795 In order to comply with these rules, a Location Recipient
796 MUST NOT redistribute a location URI without express
797 permission. Depending on the access control model, the
798 location URI might be secret (see Section 3.3 of
799 [RFC5808]).
801 Req. 10. (Full Rule language) Not Applicable: Note however that
802 Geopriv has defined a rule language capable of expressing a
803 wide range of privacy rules (see [RFC4745] and
804 [I-D.ietf-geopriv-policy].
806 Req. 11. (Limited Rule language) Not Applicable: This requirement
807 applies to (and is addressed by) PIDF-LO [RFC4119].
809 Section 7.4 of [RFC3693] details the requirements of "Location Object
810 Privacy and Security". These requirements are restated where they
811 are applicable to this document:
813 Req. 12. (Identity Protection) Compliant: Identity protection of the
814 Target is provided as long as both of the following
815 conditions are true:
817 (a) the location URI is not associated with the identity
818 of the Target in any context, and
820 (b) the PIDF-LO does not contain information about the
821 identity of the Target.
823 For instance, this requirement is complied with if the
824 protocol that conveys the location URI does not link the
825 identity of the Target to the location URI and the LS
826 doesn't include meaningful identification information in
827 the PIDF-LO document. Section 6 recommends that an
828 unlinked pseudonym is used by the LS.
830 Req. 13. (Credential Requirements) Compliant: The primary security
831 mechanism specified in this document is Transport Layer
832 Security. TLS offers the ability to use different types of
833 credentials, including symmetric, asymmetric credentials or
834 a combination of them.
836 Req. 14. (Security Features) Compliant: Geopriv defines a few
837 security requirements for the protection of Location
838 Objects such as mutual end-point authentication, data
839 object integrity, data object confidentiality and replay
840 protection. The ability to use Transport Layer security
841 fulfills most of these requirements. Authentication of
842 Location Recipients in this document relies on proof of a
843 shared secret - the location URI. This does not preclude
844 the addition of more robust authentication procedures.
846 Req. 15. (Minimal Crypto) Compliant: The mandatory to implement
847 ciphersuite is provided in the TLS layer security
848 specification.
850 Appendix B. Compliance to Location Reference Requirements
852 This section describes how HELD complies to the location reference
853 requirements stipulated in [RFC5808]. Compliance of [RFC5985] to the
854 Location Configuration Protocol is included.
856 Note that use of HELD as a location dereference protocol does not
857 necessarily imply that HELD is the corresponding LCP. This
858 document is still applicable to HTTP location URIs that are
859 acquired by other means.
861 B.1. Requirements for a Location Configuration Protocol
863 C1. "Location URI support: The location configuration protocol MUST
864 support a location reference in URI form."
866 Compliant: HELD only provides location references in URI form.
868 C2. "Location URI expiration: When a location URI has a limited
869 validity interval, its lifetime MUST be indicated."
871 Compliant: HELD indicates the expiry time of location URIs using
872 the "expires" attribute. [I-D.ietf-geopriv-policy-uri] provides
873 a way to control expiration of a location URI.
875 C3. "Location URI cancellation: The location configuration protocol
876 MUST support the ability to request a cancellation of a specific
877 location URI."
879 Compliant with Extension: [I-D.ietf-geopriv-policy-uri]
880 describes how a location URI can be cancelled through the
881 application of policy. Without extensions, HELD does not
882 provide a method for cancelling location URIs.
884 C4. "Location Information Masking: The location URI MUST ensure, by
885 default, through randomization and uniqueness, that the location
886 URI does not contain location information specific components."
888 Compliant: The HELD specification explicitly references this
889 requirement in providing guidance on the format of the location
890 URI.
892 C5. "Target Identity Protection: The location URI MUST NOT contain
893 information that identifies the Target (e.g., user or device)."
895 Compliant: The HELD specification provides specific guidance on
896 the anonymity of the Target with regards to the generation of
897 location URIs. Section 6 expands on this guidance.
899 C6. "Reuse indicator: There SHOULD be a way to allow a Target to
900 control whether a location URI can be resolved once only, or
901 multiple times."
903 Not Compliant: Specific extensions to the protocol or
904 authorization policy formats is needed to alter the default
905 behavior, which allows unlimited resolution of the location URI.
907 C7. "Selective disclosure: The location configuration protocol MUST
908 provide a mechanism that allows the Rule Maker to control what
909 information is being disclosed about the Target."
911 Compliant with Extension: Use of policy mechanisms and
912 [I-D.ietf-geopriv-policy-uri] enable this capability. Note that
913 this document recommends that only location information be
914 provided.
916 C8. "Location URI Not guessable: As a default, the location
917 configuration protocol MUST return location URIs that are random
918 and unique throughout the indicated lifetime. A location URI
919 with 128-bits of randomness is RECOMMENDED."
921 Compliant: HELD specifies that location URIs conform to this
922 requirement. The amount of randomness is not specifically
923 identified since it depends on a number of factors that change
924 over time, such as the number of valid location URIs, the
925 validity period of those URIs and the rate that guesses can be
926 made.
928 C9. "Location URI Options: In the case of user-provided
929 authorization policies, where anonymous or non-guessable
930 location URIs are not warranted, the location configuration
931 protocol MAY support a variety of optional location URI
932 conventions, as requested by a Target to a location
933 configuration server, (e.g., embedded location information
934 within the location URI)."
936 Not Compliant: HELD does not support Device-specified location
937 URI forms.
939 B.2. Requirements for a Location Dereference Protocol
941 D1. "Location URI support: The location dereference protocol MUST
942 support a location reference in URI form."
944 Compliant: HELD only provides location references in URI form.
946 D2. "Authentication: The location dereference protocol MUST include
947 mechanisms to authenticate both the client and the server."
949 Partially Compliant: TLS provides means for mutual
950 authentication. This document only specifies the required
951 mechanism for server authentication. Client authentication is
952 not precluded.
954 D3. "Dereferenced Location Form: The value returned by the
955 dereference protocol MUST contain a well-formed PIDF-LO
956 document."
958 Compliant: HELD requires that location objects are in the form
959 of a PIDF-LO that complies with [RFC5491].
961 D4. "Location URI Repeated Use: The location dereference protocol
962 MUST support the ability for the same location URI to be
963 resolved more than once, based on dereference server
964 configuration."
966 Compliant: A Location Recipient may access and use a location
967 URI as many times as desired until URI expiration results in the
968 URI being invalidated. Authorization policies might include
969 rules that modify this behavior.
971 D5. "The location dereference protocol MUST support confidentiality
972 protection of messages sent between the Location Recipient and
973 the location server."
975 Compliant: This document strongly recommends the use of TLS for
976 confidentiality and HELD mandates its implementation. Unsecured
977 HTTP is permitted: the associated risks are described in
978 Section 3.
980 Authors' Addresses
982 James Winterbottom
983 Commscope
984 Andrew Building (39)
985 Wollongong University Campus
986 Northfields Avenue
987 Wollongong, NSW 2522
988 AU
990 Phone: +61 242 212938
991 Email: james.winterbottom@commscope.com
992 Hannes Tschofenig
993 Nokia Siemens Networks
994 Linnoitustie 6
995 Espoo 02600
996 Finland
998 Phone: +358 (50) 4871445
999 Email: Hannes.Tschofenig@gmx.net
1000 URI: http://www.tschofenig.priv.at
1002 Henning Schulzrinne
1003 Columbia University
1004 Department of Computer Science
1005 450 Computer Science Building, New York, NY 10027
1006 US
1008 Phone: +1 212 939 7004
1009 Email: hgs@cs.columbia.edu
1010 URI: http://www.cs.columbia.edu
1012 Martin Thomson
1013 Microsoft
1014 3210 Porter Drive
1015 Palo Alto, CA 94304
1016 US
1018 Phone: +1 650-353-1925
1019 Email: martin.thomson@skype.net