Network Working Group H. Tschofenig
Internet-Draft Nokia Siemens Networks
Intended status: Standards Track H. Schulzrinne
Expires: January 3, 2008 Columbia University
July 2, 2007
A GEOPRIV HTTPS Using Protocol
draft-tschofenig-geopriv-http-using-protocol-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 3, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 1]
Internet-Draft GEOPRIV HTTPS Using Protocol July 2007
Abstract
This document describes an approach to to use Hypertext Transfer
Protocol (HTTP) over Transport Layer Protocol (TLS) to transport
Presence Information Data Format Location Objects (PIDF-LO) (see RFC
4119). It is a GEOPRIV using protocol as described in Section 5.2 or
RFC 3693 to resolve an identifier, which denotes a reference, to a
PIDF-LO. The document assumes that the HTTP client possesses the
reference that is obtained using a mechanism that are outside the
scope of this document and conveys it to the HTTP server in order to
retrieve a PIDF-LO in a response.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. Threat Models . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Steps for Retrieval . . . . . . . . . . . . . . . . . . . . . 8
5. Structure of Authorization Documents . . . . . . . . . . . . . 9
5.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1.1. Identity . . . . . . . . . . . . . . . . . . . . . . . 9
5.1.2. Sphere . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Matching with GEOPRIV Using Protocol Requirements . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Steps for publication . . . . . . . . . . . . . . . . . . 19
9.1.1. The client uses HTTPS to connect to the server . . . . 19
9.1.2. The client authenticates to the server . . . . . . . . 19
9.1.3. The client publishes the resource . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 2]
Internet-Draft GEOPRIV HTTPS Using Protocol July 2007
1. Introduction
This document describes a strawman approach for HTTP [2] to transport
PIDF-LO objects [3]. RFC 3693 [4], Section 5.2 says the following
about Geopriv transport protocols:
"A protocol that just transports the LO as a string of bits,
without looking at them (like an IP storage protocol could do), is
not a using protocol, but only a transport protocol.
Nevertheless, the entity or protocol that caused the transport
protocol to move the LO is responsible for the appropriate
distribution, protection, usage, retention, and storage of the LO
based on the rules that apply to that LO."
While it might be possible to describe HTTP as a transport protocol
and punt all of the requirements to the layer above HTTP, this
document describes a layering of HTTP over TLS in use between client
and server, so that a common set of mechanisms for privacy and
authentication are established.
A usage scenario envisioned by this document is described in
Figure 1.
UA Alice SIP Proxy UAS-A UAS-B UAS-C
| SIP Message | | | |
|---------------------------->| | | |
| | SIP Message + LbyR |
| |------------------------->|
| | |
| | |
| | Resolve LbyR |
| |<=========================|
| | |
| | PIDF-LO |
| |=========================>|
| | |
| SIP Message |
|<-------------------------------------------------------|
| |
| |
Figure 1: Usage Scenario: Proxy adding Reference
Another usage scenario addressed by this document is described in
Figure 2.
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 3]
Internet-Draft GEOPRIV HTTPS Using Protocol July 2007
UA Alice LCS UAS-A UAS-B UAS-C
| Request Reference | | | |
|---------------------------->| | | |
| Reference-to-LocationInfo | | | |
|<----------------------------| | | |
| | | | |
| SIP Message including Reference-to-LocationInfo |
|------------------------------------------------------->|
| | |
| | HTTPS GET with Reference |
| |<=========================|
| | |
| | PIDF-LO over HTTPS |
| |=========================>|
| |
| SIP Message |
|<-------------------------------------------------------|
| |
| |
Figure 2: Usage Scenario: End Host adding Reference
The scenario presented in Figure 2 describes a SIP User Agent Alice
using a reference to location information obtained using the Location
Configuration Protocol (LC), such as HELD [11], RELO [13] or
LocationRef [12]. This reference is then added to the SIP message to
a SIP message (as described in [14]). The SIP message travels from
the Alice via the SIP proxy to UAS-C whereby the reference might be
protected using S/MIME.
When UAS-C receives a SIP message with an included reference then it
resolves the reference to a PIDF-LO using the HTTPS mechanism
specified in this document.
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 4]
Internet-Draft GEOPRIV HTTPS Using Protocol July 2007
2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
This document furthermore uses the terminology defined in [4].
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 5]
Internet-Draft GEOPRIV HTTPS Using Protocol July 2007
3. Threat Models
HTTP can be used as a substrate to a number of different
applications, and defining a set of guidelines for conveying a
PIDF-LO for any application which might use HTTP would be difficult
or impossible. This document does not attempt that task. Instead,
it is limited in applicability to the case where a client uses an
HTTP GET request to retrieve a PIDF-LO object from a server. No
other functionality is covered. This document does not describe how
you would determine the URI of the PIDF-LO document or the
appropriate server to query.
This document assumes that the reference contains a random component
and does not contain identity information as outlined in [16].
There are three threat models that need to be described:
Authorization Policy Threat Model:
The assumption here is that the HTTP server also has has some
authorization policies and is therefore able to control access to
these policies. Consequently, when the reference is conveyed to
the potential Location Recipient (e.g., via SIP [14]), then it
does not need to be protected (neither hop-by-hop nor end-to-end).
Authentication by the Location Recipient is needed (e.g., TLS
client authentication, HTTP Digest authenticatio, etc.) to
disclose location information only to authorized entities.
End-to-End Threat Model:
In this threat model we assume that the reference is encryped end-
to-end, for example using S/MIME and an adversay is not able to
eavesdrop, modify or replay a reference. Storing authorization
policies at the Location Server is not necessary since the end
host is able to control the disclosure of the PIDF-LO by making it
available only to trusted entities. Consequently, only the entity
that is able to decrypt the end-to-end protected object (in our
case the S/MIME encrypted object) can use the reference to resolve
it to a PIDF-LO.
Hop-by-Hop Threat Model:
This threat model assumes the reference can either be directly
communication between the Target and the Location Recipient or
that involved proxies are trusted. In some cases this threat
model is also applicable the reference is conveyed to multiple
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 6]
Internet-Draft GEOPRIV HTTPS Using Protocol July 2007
Location Recipients (such as intermediaries and the final
communication end point as it is true for location-based routing).
The party that sees the reference has to be able to resolve it
into a PIDF-LO.
The first threat model requires client authentication and therefore
we describe a mechanism to apply the Geopriv authorization policy
framework (see [5] and [10]) to HTTP.
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 7]
Internet-Draft GEOPRIV HTTPS Using Protocol July 2007
4. Steps for Retrieval
1. The client uses HTTPS [6] to connect to the server.
2. The client establishes an HTTPS connection to the server, as
described in RFC 2818. At the TLS layer, the use of
TLS_NULL_WITH_NULL_NULL MUST NOT be used as the CipherSuite.
3. The client authenticates to the server.
4. The client retrieves the resource. The client retrieves the
PIDF-LO resource using an HTTP GET request.
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 8]
Internet-Draft GEOPRIV HTTPS Using Protocol July 2007
5. Structure of Authorization Documents
An authorization document is an XML document, formatted according to
the schema defined in [5]. The authorization documents used by this
document inherit the MIME type of common policy documents,
application/auth-policy+xml. As described in [5], an authorization
document is composed of rules which contain three parts - conditions,
actions, and transformations. Each action or transformation, which
is also called a permission, has the property of being a positive
grant of information to a Location Recipient. As a result, there is
a well-defined mechanism for combining actions and transformations
obtained from several sources. This mechanism is privacy safe, since
the lack of any action or transformation can only result in less
information being presented to a watcher.
This section describes how the identity and sphere elements are
instantiated. No new conditions, actions and transformations are
defined.
5.1. Conditions
5.1.1. Identity
Although the <identity> element is defined in [5], that specification
indicates that the specific usages of the framework document need to
define details that are protocol and usage specific. In particular,
it is necessary for a usage of the Common Policy framework to:
o Define acceptable means of authentication.
o Define the procedure for representing the identity of the WR
(Watcher/Requestor) as a URI or a IRI [8].
5.1.1.1. Acceptable Forms of Authentication
A request is considered authenticated if one of the following
techniques is used:
HTTP Digest:
The presence agent has authenticated the Location Recipient using
HTTP digest authentication [9].
TLS Authentication:
[[Editor's Note: More complex description since the different
identities used for TLS authentication need to be mapped to a URI
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 9]
Internet-Draft GEOPRIV HTTPS Using Protocol July 2007
or a IRI. ]]
Identity Condition within a SAML Assertion:
TBD
Since HTTP Basic authentication is not recommended it is not
described above.
5.1.1.2. Computing a URI for the Location Recipient
For requests that are authenticated using HTTP Digest, the identity
of the Location Recipient is set equal to the concatenation of the
following case-sensitive items in the given order:
1. the scheme https to 'https:'
2. the content of the username parameter (i.e., username-value) of
the as carried in the Authorization Request Header as defined in
Section 3.2.2 of [9]
3. '@' token
4. The content of the realm parameter. Note that the realm
parameter MUST be chosen in such a way that it does not contain
'@' token. [[Editor's note: Alternatively, we could relax this
restriction and determine whether it would be OK to use ':'
instead of '@' for concatenation. As an example, this would lead
to examples like Mufasa:myhost@testrealm.com]]
The concatenated parameters are alwyas a URI since the username
parameter is a URI as specified in and the realm parameter is also a
URI with the above-mentioned constraint. Consider the following
example and the respective result-URI.
digest username: alice
digest realm: example.com
URI: https:alice@example.com
5.1.2. Sphere
The <sphere> element is defined in [5]. However, each application
making use of the common policy specification needs to determine how
the presence server computes the value of the sphere to be used in
the evaluation of the condition.
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 10]
Internet-Draft GEOPRIV HTTPS Using Protocol July 2007
This document does not provide an instantiation of the <sphere>
element. Hence, the <sphere> element is not present in an
authorization policy document defined in this document.
5.2. Matching with GEOPRIV Using Protocol Requirements
This section compares the GEOPRIV requirements described in [4] with
the approach outlined in this document.
Section 7.1 of [4] details the requirements of a "Location Object".
We discuss these requirements in the subsequent list.
Req. 1. (Location Object generalities):
* Regarding requirement 1.1, the Location Object has to be
understood by the Location Recipient and the Location Server,
the two communication end points. The PIDF-LO [3] allows both
civic and geospatial location information to be used.
* Regarding requirement 1.2, a number of fields in the civic
location information format are optional.
* Regarding requirement 1.3, the civic location information is
defined in an extensible way.
* Regarding requirement 1.4, the location information itself is
not defined in this document.
* Regarding requirement 1.5, the protocol described in this
document allows the Location Recipient to resolve a reference
to a PIDF-LO only.
* Regarding requirement 1.6, the Location Object contains both
location information and privacy rules. Depending on the
deployment scenario, which is outside the scope of this
document, the privacy rules might have stronger or a weaker
semantic.
* Regarding requirement 1.7, the Location Object is usable in a
variety of protocols.
* Regarding requirement 1.8, no change regarding with respect to
the encoding of the Location Object (see RFC 4119 [3]) was made
by this document.
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 11]
Internet-Draft GEOPRIV HTTPS Using Protocol July 2007
Req. 2. (Location Object fields):
* Regarding requirement 2.1, depending on the deployment scenario
an identifier pointing to the Target may be carried inside the
PIDF-LO since the PIDF object provides the ability to carry
this identifier. In some circumstances it might be desirable
not to carry information about the Target's identity in the
PIDF-LO.
* Regarding requirement 2.2, depending on the deployment scenario
the Location Server might require that the Location Recipient
performs an authentication step. The security mechanisms for
client and server authentication are outside the scope of this
document and defined already for HTTPS itself. This document,
however, outlines how the authenticated identity is
instantiated for usage with the authorization policy framework.
* Regarding requirement 2.3, proof of possession of the Location
Recipient credentials is provided outside the scope of this
document. The security mechanisms defined for HTTPS are
utilized by this document.
* Regarding requirement 2.5, RFC 4119 defines the basis for
carrying location information in a PIDF document. The ability
to extend RFC 4119 to convey motion specific information is
work in progress.
* Regarding requirement 2.6, this document as specified only
allows the Location Recipient to resolve the reference but it
does not provide the capability to indicate which location
format or granularity has to be returned.
* Regarding requirement 2.7, the PIDF-LO relevant elements and
attributes are available. [[Editor's Note: I need to lookup
whether the PIDF-LO contains 'sighting time' and 'TTL']]
* Regarding requirement 2.8, a reference to an external (more
detailed rule set) is provided within the PIDF-LO.
* Regarding requirement 2.9, security headers and trailers are
provided Transport Layer Security.
* Regarding requirement 2.10, extensibility within the PIDF-LO is
provided regarding the definition of namespaces.
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 12]
Internet-Draft GEOPRIV HTTPS Using Protocol July 2007
Req. 3. (Location Data Types):
* Regarding requirement 3.1, RFC 4119 [3] defines geospatial
location information as the mandatory to implement location
format.
* With the support of civic and geospatial location information
in RFC 4119 [3] the requirement 3.2 is fulfilled.
* Regarding requirement 3.3, the geospatial location information
used by this document only refers to absolute coordinates.
However, the granularity of the location information can be
reduced with the help of the AltRes, LoRes, LaRes fields
described in [7].
* Regarding requirement 3.4, since the PIDF-LO format is designed
to be extensible it allows further location information to be
defined in the future.
Section 7.2 of [4] details the requirements of a "Using Protocol".
These requirements are listed below:
Req. 4.: The using protocol has to obey the privacy and security
instructions coded in the Location Object regarding the
transmission and storage of the LO. This document carries the
PIDF-LO as is via HTTPS from the Location Server to the Location
Recipient. The sending and receiving parties must obey the
instructions carried inside the object.
Req. 5.: The using protocol will typically facilitate that the keys
associated with the credentials are transported to the respective
parties, that is, key establishment is the responsibility of the
using protocol. This document does not define additional security
mechanisms beyond HTTPS.
Req. 6. (Single Message Transfer): In particular, for tracking of
small target devices, the design should allow a single message/
packet transmission of location as a complete transaction. The
encoding of the RFC 4119-defined Location Object format is not
changed. Because of the verbose XML encoding it is not tailored
towards inclusion into a single message.
Section 7.3 of [4] details the requirements of a "Rule based Location
Data Transfer". These requirements are listed below:
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 13]
Internet-Draft GEOPRIV HTTPS Using Protocol July 2007
Req. 7. (LS Rules): Depending on the deployment environment access
to location information might be controlled by authorization rules
created by the Rule Maker or by a short-lived reference that
contains a unguessable random component provided by the Target (or
by an entity on behalf of the Target).
Req. 8. (LG Rules): In context of Location-by-Reference it is not
possible that there is no relationship between the LG and the LS.
As such, the statement made in Req. 7 applies.
Req. 9. (Viewer Rules): The Rule Maker might define (via mechanisms
outside the scope of this document) which policy rules are
disclosed to other entities. These mechanisms are available with
[10].
Req. 10. (Full Rule language): Geopriv has defined a rule language
capable of expressing a wide range of privacy rules which is
applicable in the area of the distribution of Location Objects.
The format of these rules are described in [5] and [10].
Req. 11. (Limited Rule language): A limited (or basic) ruleset was
introduced with PIDF-LO [3]).
Section 7.4 of [4] details the requirements of a "Location Object
Privacy and Security". These requirements are listed below:
Req. 12 (Identity Protection): Identity protection of the Target can
be provided if (a) the protocol used to convey the reference does
not disclose the identity of the Target and (b) if the PIDF-LO
does not contain information about the identity about the Target.
Currently, there is no mechanism available that allows the Target
to tell the LS not to include identity information in the PIDF-LO.
Req. 13. (Credential Requirements): The security mechanism
specified in this document is Transport Layer Security. TLS
offers the ability to use different types of credentials,
including symmetric, asymmetric credentials or a combination of
them.
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 14]
Internet-Draft GEOPRIV HTTPS Using Protocol July 2007
Req. 14. (Security Features): Geopriv defines a few security
requirements for the protection of Location Objects such as mutual
end-point authentication, data object integrity, data object
confidentiality and replay protection. The ability to use
Transport Layer security fulfills these requirements.
Req. 15. (Minimal Crypto): [[Editor's Note: A mandatory to
implement ciphersuite has to be specified in this document.]]
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 15]
Internet-Draft GEOPRIV HTTPS Using Protocol July 2007
6. IANA Considerations
This document does not imply any actions for IANA.
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 16]
Internet-Draft GEOPRIV HTTPS Using Protocol July 2007
7. Security Considerations
This document assumes that the use of TLS as substrate to HTTP is
sufficient to protect the privacy of the PIDF-LO content while in
flight. When access control has to be applied prior to conveying the
PIDF-LO towards the Location Recipient then the content of
Section 5.1 is applicable. The description about instantiating the
identity element allows the Common Policy authorization framework to
be used. In order to make reasonable authorization decisions the
Location Recipient needs to be authenticated (e.g., using HTTP Digest
Authentication or client-side TLS authentication) or to present
authorization information in the form of a SAML assertion. There is
ongoing work to update Digest Authentication, and those may
eventually require an update to the recommended authentication
method. If access control is not applied as described in the threat
models in Section 3 then the possession of the reference to location
information that must fulfill certain charactistics (such as
containing a random component) is sufficient to obtain be authorized
to resolve the reference to a PIDF-LO.
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 17]
Internet-Draft GEOPRIV HTTPS Using Protocol July 2007
8. Acknowledgments
The authors would like to thank the GEOPRIV working group for
discussions in relationship to a Geopriv Layer 7 Location
Configuration Protocol and SIP Location Conveyance that motivate this
document.
The authors would like to thank Ted Hardie for the work with
draft-hardie-geopriv-https-strawman-00 document that served as a
basis for this document.
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 18]
Internet-Draft GEOPRIV HTTPS Using Protocol July 2007
9. Open Issues
This document contains a couple of open issues and is primarily meant
to stimulate some discussions around dereferencing of HTTPS URIs to
PIDF-LOs. A further open issue is whether a GEOPRIV using protocol
should also define steps for publication of PIDF-LOs, as described
below.
9.1. Steps for publication
9.1.1. The client uses HTTPS to connect to the server
The client establishes an HTTPS connection to the server, as
described in RFC 2818. At the TLS layer, the use of
TLS_NULL_WITH_NULL_NULL MUST NOT be used as the CipherSuite.
9.1.2. The client authenticates to the server
The client authenticates to the server using HTTP's digest
authentication mechanism as described in RFC 2617 and updated by the
errata.
9.1.3. The client publishes the resource
The client publishes the PIDF-LO resource using an HTTP PUT request.
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 19]
Internet-Draft GEOPRIV HTTPS Using Protocol July 2007
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[3] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[4] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004.
[5] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk,
J., and J. Rosenberg, "Common Policy: A Document Format for
Expressing Privacy Preferences", RFC 4745, February 2007.
[6] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[7] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004.
[8] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005.
[9] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
10.2. Informative References
[10] Schulzrinne, H., "Geolocation Policy: A Document Format for
Expressing Privacy Preferences for Location Information",
draft-ietf-geopriv-policy-12 (work in progress), May 2007.
[11] Barnes, M., "HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-00 (work in
progress), June 2007.
[12] Schulzrinne, H., "A Location Reference Event Package for the
Session Initiation Protocol (SIP)",
draft-schulzrinne-geopriv-locationref-00 (work in progress),
October 2006.
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 20]
Internet-Draft GEOPRIV HTTPS Using Protocol July 2007
[13] Schulzrinne, H., "RELO: Retrieving End System Location
Information", draft-schulzrinne-geopriv-relo-03 (work in
progress), March 2007.
[14] Polk, J. and B. Rosen, "Session Initiation Protocol Location
Conveyance", draft-ietf-sip-location-conveyance-07 (work in
progress), February 2007.
[15] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location
Configuration Protocol; Problem Statement and Requirements",
draft-ietf-geopriv-l7-lcp-ps-02 (work in progress), April 2007.
[16] Marshall, R., "Requirements for a Location-by-Reference
Mechanism used in Location Configuration and Conveyance",
draft-marshall-geopriv-lbyr-requirements-01 (work in progress),
March 2007.
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 21]
Internet-Draft GEOPRIV HTTPS Using Protocol July 2007
Authors' Addresses
Hannes Tschofenig
Nokia Siemens Networks
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Phone: +49 89 636 40390
Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 22]
Internet-Draft GEOPRIV HTTPS Using Protocol July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Tschofenig & Schulzrinne Expires January 3, 2008 [Page 23]