draft-ietf-geopriv-deref-protocol-01.txt   draft-ietf-geopriv-deref-protocol-02.txt 
GEOPRIV J. Winterbottom GEOPRIV J. Winterbottom
Internet-Draft Andrew Corporation Internet-Draft Andrew Corporation
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: April 2, 2011 Nokia Siemens Networks Expires: June 19, 2011 Nokia Siemens Networks
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
M. Thomson M. Thomson
M. Dawson M. Dawson
Andrew Corporation Andrew Corporation
September 29, 2010 December 16, 2010
A Location Dereferencing Protocol Using HELD A Location Dereferencing Protocol Using HELD
draft-ietf-geopriv-deref-protocol-01 draft-ietf-geopriv-deref-protocol-02
Abstract Abstract
This document describes how to use the Hypertext Transfer Protocol This document describes how to use the Hypertext Transfer Protocol
(HTTP) over Transport Layer Security (TLS) as a dereferencing (HTTP) over Transport Layer Security (TLS) as a dereferencing
protocol to resolve a reference to a Presence Information Data Format protocol to resolve a reference to a Presence Information Data Format
Location Object (PIDF-LO). The document assumes that a Location Location Object (PIDF-LO). The document assumes that a Location
Recipient possesses a secure HELD URI that can be used in conjunction Recipient possesses a URI that can be used in conjunction with the
with the HELD protocol to request the location of the Target. HELD protocol to request the location of the Target.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 2, 2011. This Internet-Draft will expire on June 19, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
3.3. Access Control with HELD Deference . . . . . . . . . . . . 7 3.3. Access Control with HELD Deference . . . . . . . . . . . . 7
4. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 8 4. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 8
4.1. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 9 4.1. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 9
4.2. HTTP GET Behavior . . . . . . . . . . . . . . . . . . . . 9 4.2. HTTP GET Behavior . . . . . . . . . . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative references . . . . . . . . . . . . . . . . . . 15 9.2. Informative references . . . . . . . . . . . . . . . . . . 14
Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 16 Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 16
Appendix B. Compliance to Location Reference Requirements . . . . 19 Appendix B. Compliance to Location Reference Requirements . . . . 19
B.1. Requirements for a Location Configuration Protocol . . . . 19 B.1. Requirements for a Location Configuration Protocol . . . . 19
B.2. Requirements for a Location Dereference Protocol . . . . . 21 B.2. Requirements for a Location Dereference Protocol . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Provision of location information by reference [RFC5808] involves the Provision of location information by reference [RFC5808] involves the
creation of a resource that is identified by a "location URI". A creation of a resource that is identified by a "location URI". A
"location URI" identifies resource that contains the location of an "location URI" is a URI [RFC3986] that identifies a resource
entity. A location URI might be a temporary resource, created in containing the location of an entity. A location URI might identify
response to a HTTP-Enabled Location Delivery (HELD) a temporary resource, created in response to a HTTP-Enabled Location
[I-D.ietf-geopriv-http-location-delivery] request. A location URI Delivery (HELD) [RFC5985] request. A location URI does not
does not intrinsically include location information, instead the URI intrinsically include location information, instead the URI is
is "dereferenced" by a Location Recipient to acquire location "dereferenced" by a Location Recipient to acquire location
information. This document specifies how a holder of a location URI information. This document specifies how a holder of a location URI
uses that URI to retrieve location information. uses that URI to retrieve location information.
The HELD protocol, as described in HELD defines a use of HTTP that enables location configuration - the
[I-D.ietf-geopriv-http-location-delivery], defines a use of HTTP that process where a Device acquires location information about itself. A
enables location configuration - the process where a Device acquires part of location configuration is the provision of a location URI.
location information about itself. A part of location configuration However, HELD does not describe how such a URI is used; this document
is the provision of a location URI. However, HELD does not describe provides that definition.
how such a URI is used; this document provides that definition.
This document defines how HELD is used by a Location Recipient to This document defines how HELD is used by a Location Recipient to
dereference a location URI and acquire location information. The dereference a location URI and acquire location information. The
result of this process is location object in the form of a Presence result of this process is a location object in the form of a Presence
Information Data Format - Location Object (PIDF-LO) document Information Data Format - Location Object (PIDF-LO) document
[RFC4119]. A constrained set of HELD features are defined such that [RFC4119]. A constrained set of HELD features are defined such that
it is suitable for use as a location dereference protocol [RFC5808]. it is suitable for use as a location dereference protocol [RFC5808].
Use as a location dereference protocol requires use of the Transport Use as a location dereference protocol requires use of the Transport
Layer Security (TLS) binding for HTTP [RFC2818] in order to provide Layer Security (TLS) binding for HTTP [RFC2818] in order to provide
confidentiality, authentication and protection from modification. confidentiality, authentication and protection from modification.
Use of HELD as a dereferencing protocol has the advantage that the Use of HELD as a dereferencing protocol has the advantage that the
Location Recipient can indicate the type of location information it Location Recipient can indicate the type of location information it
would like to receive. This functionality is already available with would like to receive. This functionality is already available with
the HELD base specification, described in the HELD base specification, described in [RFC5985]. Furthermore,
[I-D.ietf-geopriv-http-location-delivery]. Furthermore, the HELD the HELD response from the LIS towards the Location Recipient not
response from the LIS towards the Location Recipient not only only provides the PIDF-LO but also encapsulates supplementary
provides the PIDF-LO but also encapsulates supplementary information, information, such as error messages, back to the Location Recipient.
such as error messages, back to the Location Recipient.
Location URIs created for use with HELD dereferencing use the Location URIs created for use with HELD dereferencing use the
"https:" or "http:" scheme. The behaviour described in this document "https:" or "http:" scheme. The behaviour described in this document
can be used by Location Recipients that are aware of the fact that can be used by Location Recipients that are aware of the fact that
the URI is a location URI. the URI is a location URI.
An example scenario envisioned by this document is shown in Figure 1. An example scenario envisioned by this document is shown in Figure 1.
This diagram shows how a location dereference protocol fits with This diagram shows how a location dereference protocol fits with
location configuration and conveyance. [RFC5808] contains more location configuration and conveyance. [RFC5808] contains more
information on this scenario and others like it. information on this scenario and others like it.
skipping to change at page 6, line 40 skipping to change at page 6, line 40
Authorization by possession uses a very simple policy that does not Authorization by possession uses a very simple policy that does not
typically require direct interaction with a Rule Maker; it is assumed typically require direct interaction with a Rule Maker; it is assumed
that the Rule Maker is able to exert control over the distribution of that the Rule Maker is able to exert control over the distribution of
the location URI. Therefore, the LIS can operate with limited policy the location URI. Therefore, the LIS can operate with limited policy
input from a Rule Maker. input from a Rule Maker.
Limited disclosure is an important aspect of this authorization Limited disclosure is an important aspect of this authorization
model. The location URI is a secret; therefore, ensuring that model. The location URI is a secret; therefore, ensuring that
adversaries are not able to acquire this information is paramount. adversaries are not able to acquire this information is paramount.
Encryption, such as might be offered by TLS [RFC5246] or S/MIME Encryption, such as might be offered by TLS [RFC5246] or S/MIME
[RFC3851], protects the information from eavesdroppers. [RFC5751], protects the information from eavesdroppers.
Use of authorization by possession location URIs in a hop-by-hop Use of authorization by possession location URIs in a hop-by-hop
protocol such as SIP [RFC3261] adds the possibility of on-path protocol such as SIP [RFC3261] adds the possibility of on-path
adversaries. Depending on the usage of the location URI for certain adversaries. Depending on the usage of the location URI for certain
location based applications (e.g., emergency services, location based location based applications (e.g., emergency services, location based
routing) specific treatment is important, as discussed in routing) specific treatment is important, as discussed in
[I-D.ietf-sipcore-location-conveyance]. [I-D.ietf-sipcore-location-conveyance].
Using possession as a basis for authorization means that, once Using possession as a basis for authorization means that, once
granted, authorization cannot be easily revoked. Cancellation of a granted, authorization cannot be easily revoked. Cancellation of a
skipping to change at page 9, line 19 skipping to change at page 9, line 19
dependent on the Location Recipient identity. Future specifications dependent on the Location Recipient identity. Future specifications
could define an authentication mechanism and a means by which could define an authentication mechanism and a means by which
Location Recipients are identified in authorization policies. This Location Recipients are identified in authorization policies. This
document provides definitions for neither item. document provides definitions for neither item.
4.1. HELD Usage Profile 4.1. HELD Usage Profile
Use of HELD as a location dereference protocol is largely the same as Use of HELD as a location dereference protocol is largely the same as
its use as a location configuration protocol. Aside from the its use as a location configuration protocol. Aside from the
restrictions noted in this document, HELD semantics do not differ restrictions noted in this document, HELD semantics do not differ
from those established in [I-D.ietf-geopriv-http-location-delivery]. from those established in [RFC5985].
The HELD "locationRequest" is the only request permitted by this The HELD "locationRequest" is the only request permitted by this
specification. Similarly, request parameters other than the specification. Similarly, request parameters other than the
following MUST NOT be accepted by the LS: "responseTime", following MUST NOT be accepted by the LS: "responseTime",
"locationType" (including the associated "exact" attribute). "locationType" (including the associated "exact" attribute).
Parameters and requests that do not have known behaviour for Parameters and requests that do not have known behaviour for
dereference requests MUST NOT be used. The LS MUST ignore any dereference requests MUST NOT be used. The LS MUST ignore any
parameters that it does not understand unless it knows the parameters parameters that it does not understand unless it knows the parameters
to be invalid. If parameters are known to be invalid, the LS MAY to be invalid. If parameters are understood by the LS and known to
generate a HELD error response. For instance, those defined in be invalid, the LS MAY generate a HELD error response. For instance,
[I-D.ietf-geopriv-held-identity-extensions] are always invalid and those defined in [I-D.ietf-geopriv-held-identity-extensions] are
can be rejected. always invalid and can be rejected.
The LS MUST NOT generate location URIs or provide a "locationUriSet" The LS MUST NOT generate location URIs or provide a "locationUriSet"
in response to a dereference request. If the location request in response to a dereference request. If the location request
contains a "locationType" element that includes "locationURI", this contains a "locationType" element that includes "locationURI", this
parameter is either ignored or rejected as appropriate, based on the parameter is either ignored or rejected as appropriate, based on the
associated "exact" attribute. associated "exact" attribute.
4.2. HTTP GET Behavior 4.2. HTTP GET Behavior
GET is the method assumed by generic HTTP user agents, therefore GET is the method assumed by generic HTTP user agents, therefore
skipping to change at page 10, line 17 skipping to change at page 10, line 17
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="false"> <locationType exact="false">
geodetic civic geodetic civic
</locationType> </locationType>
</locationRequest> </locationRequest>
Figure 3: GET Request Equivalent Location Request Figure 3: GET Request Equivalent Location Request
HTTP GET requests must be safe and idempotent [RFC2616] - that is, HTTP GET requests must be safe and idempotent [RFC2616] - that is,
there are no side-effects of making the request. Only when a there are no side-effects of making the request and a repeated
location URI is created does HELD request have side-effects. A request has no more effect than a single request. Only when a
request to a location URI can be both safe and idempotent, since a location URI is created does HELD request have side-effects.
Repeating a HELD request might result in a different location, but
only as a result of a change in the state of the resource: the
location of the Target.
A request to a location URI can be both safe and idempotent, since a
location URI cannot be produced in response to a request to a location URI cannot be produced in response to a request to a
location URI. location URI.
Note: Idempotence does not require that the same answer be provided
to different requests only that there are no side effects.
Changes in the response can occur for a number of reasons,
including a change in the value of the resource: the location of
the Target.
Content negotiation MAY be supported to produce a presence document Content negotiation MAY be supported to produce a presence document
in place of a HELD location response. Where the presence document in place of a HELD location response. Where the presence document
would otherwise be included in a "locationResponse" document, it can would otherwise be included in a "locationResponse" document, it can
be included in the body of the HTTP response directly. be included in the body of the HTTP response directly by including an
"Accept" header that includes "application/pidf+xml".
5. Examples 5. Examples
The example in Figure 4 shows the simplest form of dereferencing The example in Figure 4 shows the simplest form of dereferencing
request using HELD to the location URI request using HELD to the location URI
"https://ls.example.com:49152/uri/w3g61nf5n66p0". The only way that "https://ls.example.com:49152/uri/w3g61nf5n66p0". The only way that
this differs from the example in Section 10.1 of this differs from the example in Section 10.1 of [RFC5985] is in the
[I-D.ietf-geopriv-http-location-delivery] is in the request URI and request URI and the source of the URI.
the source of the URI.
POST /uri/w3g61nf5n66p0 HTTP/1.1 POST /uri/w3g61nf5n66p0 HTTP/1.1
Host: ls.example.com:49152 Host: ls.example.com:49152
Content-Type: application/held+xml Content-Type: application/held+xml
Content-Length: 87 Content-Length: 87
<?xml version="1.0"?> <?xml version="1.0"?>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
Figure 4: Minimal Dereferencing Request Figure 4: Minimal Dereferencing Request
Figure 5 shows the response to the previous request listing both Figure 5 shows the response to the previous request listing both
civic and geodetic location information of the Target's location. civic and geodetic location information of the Target's location.
Again, this is identical to the response in Section 10.1 of Again, this is identical to the response in Section 10.1 of [RFC5985]
[I-D.ietf-geopriv-http-location-delivery] - unless policy specfies - unless policy specfies otherwise, the Location Recipient receives
otherwise, the Location Recipient receives the same information as the same information as the Device.
the Device.
HTTP/1.1 200 OK HTTP/1.1 200 OK
Server: Example LIS Server: Example LIS
Date: Mon, 10 Jan 2011 03:42:29 GMT Date: Mon, 10 Jan 2011 03:42:29 GMT
Expires: Tue, 11 Jan 2011 03:42:29 GMT Expires: Tue, 11 Jan 2011 03:42:29 GMT
Cache-control: private Cache-control: private
Content-Type: application/held+xml Content-Type: application/held+xml
Content-Length: 676 Content-Length: 676
<?xml version="1.0"?> <?xml version="1.0"?>
skipping to change at page 13, line 13 skipping to change at page 13, line 13
means of ensuring confidentiality of location information through means of ensuring confidentiality of location information through
encryption and mutual authentication. An authorization policy allows encryption and mutual authentication. An authorization policy allows
a Rule Maker to explicitly control how location information is a Rule Maker to explicitly control how location information is
provided to Location Recipients. provided to Location Recipients.
The process by which a Rule Maker establishes an authorization policy The process by which a Rule Maker establishes an authorization policy
is not covered by this document; several methods are possible, for is not covered by this document; several methods are possible, for
instance: [I-D.barnes-geopriv-policy-uri], [RFC4825]. instance: [I-D.barnes-geopriv-policy-uri], [RFC4825].
Use of TLS for the dereferencing of location URIs is strongly Use of TLS for the dereferencing of location URIs is strongly
RECOMMENDED, as discussed in Section 4.1. Location Recipients MUST RECOMMENDED, as discussed in Section 4. Location Recipients MUST
authenticate the host identity using the domain name included in the authenticate the host identity using the domain name included in the
location URI, using the procedure described in Section 3.1 of location URI, using the procedure described in Section 3.1 of
[RFC2818]. Local policy determines what a Location Recipient does if [RFC2818]. Local policy determines what a Location Recipient does if
authentication fails or cannot be attempted. authentication fails or cannot be attempted.
The authorization by possession model (Section 3.1) further relies on The authorization by possession model (Section 3.1) further relies on
TLS when transmitting the location URI to protect the secrecy of the TLS when transmitting the location URI to protect the secrecy of the
URI. Possession of such a URI implies the same privacy URI. Possession of such a URI implies the same privacy
considerations as possession of the PIDF-LO document that the URI considerations as possession of the PIDF-LO document that the URI
references. references.
skipping to change at page 14, line 14 skipping to change at page 14, line 14
8. Acknowledgements 8. Acknowledgements
Thanks to Barbara Stark and Guy Caron for providing early comments. Thanks to Barbara Stark and Guy Caron for providing early comments.
Thanks to Rohan Mahy for constructive comments on the scope and Thanks to Rohan Mahy for constructive comments on the scope and
format of the document. Thanks to Ted Hardie for his strawman format of the document. Thanks to Ted Hardie for his strawman
proposal that provided assistance with the security section of this proposal that provided assistance with the security section of this
document. Richard Barnes made helpful observations on the document. Richard Barnes made helpful observations on the
application of authorization policy. application of authorization policy.
The Participants of the GEOPRIV interim meeting 2008 provided The participants of the GEOPRIV interim meeting 2008 provided
significant feedback on this document. significant feedback on this document.
James Polk provided input on security in June 2008. James Polk provided input on security in June 2008.
9. References 9. References
9.1. Normative References 9.1. Normative References
[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-16 (work in
progress), August 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35,
RFC 4395, February 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009. RFC 5491, March 2009.
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
RFC 5985, September 2010.
9.2. Informative references 9.2. Informative references
[I-D.barnes-geopriv-policy-uri] [I-D.barnes-geopriv-policy-uri]
Barnes, R., Thomson, M., and J. Winterbottom, "Location Barnes, R., Thomson, M., Winterbottom, J., and H.
Configuration Extensions for Policy Management", Tschofenig, "Location Configuration Extensions for Policy
draft-barnes-geopriv-policy-uri-01 (work in progress), Management", draft-barnes-geopriv-policy-uri-02 (work in
May 2010. progress), November 2010.
[I-D.ietf-geopriv-arch] [I-D.ietf-geopriv-arch]
Barnes, R., Lepinski, M., Cooper, A., Morris, J., Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications", Location and Location Privacy in Internet Applications",
draft-ietf-geopriv-arch-02 (work in progress), May 2010. draft-ietf-geopriv-arch-03 (work in progress),
October 2010.
[I-D.ietf-geopriv-held-identity-extensions] [I-D.ietf-geopriv-held-identity-extensions]
Winterbottom, J., Thomson, M., Tschofenig, H., and R. Winterbottom, J., Thomson, M., Tschofenig, H., and R.
Barnes, "Use of Device Identity in HTTP-Enabled Location Barnes, "Use of Device Identity in HTTP-Enabled Location
Delivery (HELD)", Delivery (HELD)",
draft-ietf-geopriv-held-identity-extensions-04 (work in draft-ietf-geopriv-held-identity-extensions-06 (work in
progress), June 2010. progress), November 2010.
[I-D.ietf-geopriv-policy] [I-D.ietf-geopriv-policy]
Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
and J. Polk, "Geolocation Policy: A Document Format for and J. Polk, "Geolocation Policy: A Document Format for
Expressing Privacy Preferences for Location Information", Expressing Privacy Preferences for Location Information",
draft-ietf-geopriv-policy-21 (work in progress), draft-ietf-geopriv-policy-22 (work in progress),
January 2010. October 2010.
[I-D.ietf-sipcore-location-conveyance] [I-D.ietf-sipcore-location-conveyance]
Polk, J., Rosen, B., and J. Peterson, "Location Conveyance Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
for the Session Initiation Protocol", for the Session Initiation Protocol",
draft-ietf-sipcore-location-conveyance-03 (work in draft-ietf-sipcore-location-conveyance-04 (work in
progress), July 2010. progress), October 2010.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
Polk, J., and J. Rosenberg, "Common Policy: A Document Polk, J., and J. Rosenberg, "Common Policy: A Document
Format for Expressing Privacy Preferences", RFC 4745, Format for Expressing Privacy Preferences", RFC 4745,
February 2007. February 2007.
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007. Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol: Problem Statement and Location Configuration Protocol: Problem Statement and
Requirements", RFC 5687, March 2010. Requirements", RFC 5687, March 2010.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[RFC5808] Marshall, R., "Requirements for a Location-by-Reference [RFC5808] Marshall, R., "Requirements for a Location-by-Reference
Mechanism", RFC 5808, May 2010. Mechanism", RFC 5808, May 2010.
Appendix A. GEOPRIV Using Protocol Compliance Appendix A. GEOPRIV Using Protocol Compliance
This section describes how use of HELD as a location dereference This section describes how use of HELD as a location dereference
protocol complies with the GEOPRIV requirements described in protocol complies with the GEOPRIV requirements described in
[RFC3693]. [RFC3693].
Req. 1. (Location Object generalities): Req. 1. (Location Object generalities):
skipping to change at page 19, line 30 skipping to change at page 19, line 23
shared secret - the location URI. This does not preclude shared secret - the location URI. This does not preclude
the addition of more robust authentication procedures. the addition of more robust authentication procedures.
Req. 15. (Minimal Crypto) Compliant: The mandatory to implement Req. 15. (Minimal Crypto) Compliant: The mandatory to implement
ciphersuite is provided in the TLS layer security ciphersuite is provided in the TLS layer security
specification. specification.
Appendix B. Compliance to Location Reference Requirements Appendix B. Compliance to Location Reference Requirements
This section describes how HELD complies to the location reference This section describes how HELD complies to the location reference
requirements stipulated in [RFC5808]. Compliance to the Location requirements stipulated in [RFC5808]. Compliance of [RFC5985] to the
Configuration Protocol are included in this document. Location Configuration Protocol is included.
Note that use of HELD as a location dereference protocol does not Note that use of HELD as a location dereference protocol does not
necessarily imply that HELD is the corresponding LCP. This necessarily imply that HELD is the corresponding LCP. This
document is still applicable to HTTP location URIs that are document is still applicable to HTTP location URIs that are
acquired by other means. acquired by other means.
B.1. Requirements for a Location Configuration Protocol B.1. Requirements for a Location Configuration Protocol
C1. "Location URI support: The location configuration protocol MUST C1. "Location URI support: The location configuration protocol MUST
support a location reference in URI form." support a location reference in URI form."
skipping to change at page 22, line 11 skipping to change at page 21, line 49
URI as many times as desired until URI expiration results in the URI as many times as desired until URI expiration results in the
URI being invalidated. Authorization policies might include URI being invalidated. Authorization policies might include
rules that modify this behavior. rules that modify this behavior.
D5. "The location dereference protocol MUST support confidentiality D5. "The location dereference protocol MUST support confidentiality
protection of messages sent between the Location Recipient and protection of messages sent between the Location Recipient and
the location server." the location server."
Compliant: This document strongly recommends the use of TLS for Compliant: This document strongly recommends the use of TLS for
confidentiality and HELD mandates its implementation. Unsecured confidentiality and HELD mandates its implementation. Unsecured
HTTP is permitted, and some of the associated risks are HTTP is permitted: the associated risks are described in
described in Section 4.1. Section 4.
Authors' Addresses Authors' Addresses
James Winterbottom James Winterbottom
Andrew Corporation Andrew Corporation
Andrew Building (39) Andrew Building (39)
Wollongong University Campus Wollongong University Campus
Northfields Avenue Northfields Avenue
Wollongong, NSW 2522 Wollongong, NSW 2522
AU AU
 End of changes. 32 change blocks. 
82 lines changed or deleted 69 lines changed or added

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