draft-ietf-geopriv-deref-protocol-05.txt   draft-ietf-geopriv-deref-protocol-06.txt 
GEOPRIV J. Winterbottom GEOPRIV J. Winterbottom
Internet-Draft Commscope Internet-Draft Commscope
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: November 9, 2012 Nokia Siemens Networks Expires: January 13, 2013 Nokia Siemens Networks
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
M. Thomson M. Thomson
(Unaffiliated) (Unaffiliated)
May 8, 2012 July 12, 2012
A Location Dereferencing Protocol Using HELD A Location Dereferencing Protocol Using HELD
draft-ietf-geopriv-deref-protocol-05 draft-ietf-geopriv-deref-protocol-06
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 URI that can be used in conjunction with the Recipient possesses a URI that can be used in conjunction with the
HTTP-Enabled Location Delivery (HELD) protocol to request the HTTP-Enabled Location Delivery (HELD) protocol to request the
location of the Target. location of the Target.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 9, 2012. This Internet-Draft will expire on January 13, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 28 skipping to change at page 4, line 28
Note: In many cases, an "http:" URI does not provide sufficient Note: In many cases, an "http:" URI does not provide sufficient
security for location URIs. The absence of the security security for location URIs. The absence of the security
mechanisms provided by TLS means that the Rule Maker has no mechanisms provided by TLS means that the Rule Maker has no
control over who receives location information and the Location control over who receives location information and the Location
Recipient has no assurance that the information is correct. Recipient has no assurance that the information is correct.
The Location Recipient establishes a connection to the LS, as The Location Recipient establishes a connection to the LS, as
described in [RFC2818]. described in [RFC2818].
TLS SHOULD be used. When TLS is used, the TLS ciphersuite TLS MUST be used unless confidentiality and integrity are provided by
TLS_NULL_WITH_NULL_NULL MUST NOT be used and the LS MUST be some other mechanism, such as IPsec or a fully trusted network.
authenticated [RFC6125] to ensure that the correct server is Without a reliable assertion that a mechanism is in place, such as
contacted. through configuration or user override, then TLS MUST be used. When
TLS is used, the TLS ciphersuite TLS_NULL_WITH_NULL_NULL MUST NOT be
used and the LS MUST be authenticated [RFC6125] to ensure that the
correct server is contacted.
A Location Server MAY reject a request and request that a Location A Location Server MAY reject a request and request that a Location
Recipient provide authentication credentials if authorization is Recipient provide authentication credentials if authorization is
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.
3.1. HELD Usage Profile 3.1. HELD Usage Profile
skipping to change at page 7, line 21 skipping to change at page 7, line 24
"http:" URI is dereferenced as described in this document; other "http:" URI is dereferenced as described in this document; other
URI schemes might be dereferenced using another method. URI schemes might be dereferenced using another method.
In this final step, the Location Server (LS) or LIS makes an In this final step, the Location Server (LS) or LIS makes an
authorization decision. How this decision is reached depends on the authorization decision. How this decision is reached depends on the
authorization model. authorization model.
4.1. Authorization by Possession 4.1. Authorization by Possession
In this model, possession - or knowledge - of the location URI is In this model, possession - or knowledge - of the location URI is
used to control access to location information. A location URI is used to control access to location information. A location URI might
constructed such that it is hard to guess (see C8 of [RFC5808]) and be constructed such that it is hard to guess (see C8 of [RFC5808])
the set of entities that it is disclosed to is limited. The only and the set of entities that it is disclosed to can be limited. The
authentication required by the LS is evidence of possession of the only authentication this would require by the LS is evidence of
URI. The LS is able to immediately authorize any request that possession of the URI. The LS could immediately authorize any
indicates this URI. request that indicates this URI.
Authorization by possession uses a very simple policy that does not Authorization by possession does not require direct interaction with
typically require direct interaction with a Rule Maker; it is assumed a Rule Maker; it is assumed that the Rule Maker is able to exert
that the Rule Maker is able to exert control over the distribution of control over the distribution of the location URI. Therefore, the
the location URI. Therefore, the LIS can operate with limited policy 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
[RFC5751], 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
skipping to change at page 8, line 6 skipping to change at page 8, line 8
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
location URI ensures that legitimate users are also affected; location URI ensures that legitimate users are also affected;
application of additional policy is theoretically possible, but could application of additional policy is theoretically possible, but could
be technically infeasible. Expiration of location URIs limits the be technically infeasible. Expiration of location URIs limits the
usable time for a location URI, requiring that an attacker continue usable time for a location URI, requiring that an attacker continue
to learn new location URIs to retain access to current location to learn new location URIs to retain access to current location
information. information.
A very simple policy is established at the time that a location URI A very simple policy might be established at the time that a location
is created. This policy specifies that the location URI expires URI is created. This policy specifies that the location URI expires
after a certain time, which limits any inadvertent exposure of after a certain time, which limits any inadvertent exposure of
location information to adversaries. The expiration time of the location information to adversaries. The expiration time of the
location URI might be negotiated at the time of its creation, or it location URI might be negotiated at the time of its creation, or it
might be unilaterally set by the LIS. might be unilaterally set by the LIS.
4.2. Authorization via Access Control 4.2. Authorization via Access Control
Use of explicit access control provides a Rule Maker greater control Use of explicit access control provides a Rule Maker greater control
over the behaviour of an LS. In contrast to authorization by over the behaviour of an LS. In contrast to authorization by
possession, possession of this form of location URI does not imply possession, possession of this form of location URI does not imply
skipping to change at page 13, line 12 skipping to change at page 13, line 12
to protect privacy: TLS and authorization policies. TLS provides a to protect privacy: TLS and authorization policies. TLS provides a
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.ietf-geopriv-policy-uri], [RFC4825]. instance: [I-D.ietf-geopriv-policy-uri], [RFC4825].
Use of TLS for the dereferencing of location URIs is strongly TLS MUST be used for dereferencing location URIs unless
RECOMMENDED, as discussed in Section 3. Location Recipients MUST confidentiality and integrity are provided by some other mechanism,
authenticate the host identity using the domain name included in the as discussed in Section 3. Location Recipients MUST authenticate the
location URI, using the procedure described in Section 3.1 of host identity using the domain name included in the location URI,
[RFC2818]. Local policy determines what a Location Recipient does if using the procedure described in Section 3.1 of [RFC2818]. Local
authentication fails or cannot be attempted. policy determines what a Location Recipient does if authentication
fails or cannot be attempted.
The authorization by possession model (Section 4.1) further relies on The authorization by possession model (Section 4.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.
Location URIs MUST only be disclosed to authorized Location Location URIs MUST only be disclosed to authorized Location
Recipients. The GEOPRIV architecture [RFC6280] identifies the Rule Recipients. The GEOPRIV architecture [RFC6280] identifies the Rule
Maker role as being the entity that authorizes disclosure of this Maker role as being the entity that authorizes disclosure of this
skipping to change at page 15, line 14 skipping to change at page 15, line 14
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
9.2. Informative references 9.2. Informative references
[I-D.ietf-geopriv-dhcp-lbyr-uri-option] [I-D.ietf-geopriv-dhcp-lbyr-uri-option]
Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4
and IPv6 Option for a Location Uniform Resource Identifier and IPv6 Option for a Location Uniform Resource Identifier
(URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-14 (work (URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-15 (work
in progress), March 2012. in progress), May 2012.
[I-D.ietf-geopriv-policy] [I-D.ietf-geopriv-policy]
Cuellar, J., Tschofenig, H., Schulzrinne, H., Polk, J., Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J.,
Morris, J., and M. Thomson, "Geolocation Policy: A Morris, J., and M. Thomson, "Geolocation Policy: A
Document Format for Expressing Privacy Preferences for Document Format for Expressing Privacy Preferences for
Location Information", draft-ietf-geopriv-policy-25 (work Location Information", draft-ietf-geopriv-policy-26 (work
in progress), October 2011. in progress), June 2012.
[I-D.ietf-geopriv-policy-uri] [I-D.ietf-geopriv-policy-uri]
Thomson, M., Winterbottom, J., Barnes, R., and H. Thomson, M., Winterbottom, J., Barnes, R., and H.
Tschofenig, "Location Configuration Extensions for Policy Tschofenig, "Location Configuration Extensions for Policy
Management", draft-ietf-geopriv-policy-uri-04 (work in Management", draft-ietf-geopriv-policy-uri-04 (work in
progress), November 2011. progress), November 2011.
[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,
 End of changes. 12 change blocks. 
32 lines changed or deleted 35 lines changed or added

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