draft-ietf-geopriv-deref-protocol-06.txt   draft-ietf-geopriv-deref-protocol-07.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: January 13, 2013 Nokia Siemens Networks Expires: January 15, 2013 Nokia Siemens Networks
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
M. Thomson M. Thomson
(Unaffiliated) Microsoft
July 12, 2012 July 14, 2012
A Location Dereferencing Protocol Using HELD A Location Dereferencing Protocol Using HELD
draft-ietf-geopriv-deref-protocol-06 draft-ietf-geopriv-deref-protocol-07
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 January 13, 2013. This Internet-Draft will expire on January 15, 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 MUST be used unless confidentiality and integrity are provided by The scheme of a location URI determines whether or not TLS is used on
some other mechanism, such as IPsec or a fully trusted network. a given dereference transaction. Location Servers MUST be configured
Without a reliable assertion that a mechanism is in place, such as to issue only HTTPS URIs and respond to only to HTTPS dereference
through configuration or user override, then TLS MUST be used. When requests, unless confidentiality and integrity protection are
TLS is used, the TLS ciphersuite TLS_NULL_WITH_NULL_NULL MUST NOT be provided by some other mechanism. For example, the server might only
used and the LS MUST be authenticated [RFC6125] to ensure that the accept requests from clients within a trusted network, or via an
correct server is contacted. IPsec-protected channel. 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 23, line 25 skipping to change at page 23, line 25
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building, New York, NY 10027 450 Computer Science Building, New York, NY 10027
US US
Phone: +1 212 939 7004 Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu Email: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu URI: http://www.cs.columbia.edu
Martin Thomson Martin Thomson
(Unaffiliated) Microsoft
. 3210 Porter Drive
Mountain View, CA 94043 Palo Alto, CA 94304
US US
Phone: +1 650-353-1925 Phone: +1 650-353-1925
Email: martin.thomson@gmail.com Email: martin.thomson@skype.net
 End of changes. 7 change blocks. 
15 lines changed or deleted 18 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/