Geopriv R. Barnes Internet-Draft M. Lepinski Updates: 3693, 3694 BBN Technologies (if approved) H. Tschofenig Intended status: Informational Nokia Siemens Networks Expires: May 22, 2008 H. Schulzrinne Columbia University November 19, 2007 Security Requirements for the Geopriv Location System draft-barnes-geopriv-lo-sec-01 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 May 22, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Internet protocols that deal with presence-based location objects support a wide variety of applications. However, the dissemination of location objects from sources of location to consumers is a common feature of all location-based applications. In order to enable the Barnes, et al. Expires May 22, 2008 [Page 1]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007 development of broadly-applicable security and privacy mechanisms for dissemination of location objects, this document describes an end-to- end architecture for policy-constrained location distribution. In this architecture, location distribution is accomplished by a set of distribute actors. Likewise, we describe the assurances that these actors require from the architecture, and derive more detailed security requirements based on these assurances. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. An End-to-end Location Architecture . . . . . . . . . . . . . 4 3.1. Structure of a Location Transmission . . . . . . . . . . . 5 3.2. The End-to-end Model and Global Roles . . . . . . . . . . 7 3.3. Usage Scenarios for this Model . . . . . . . . . . . . . . 8 3.3.1. RFC 3693 model of transmission . . . . . . . . . . . . 8 3.3.2. Location configuration by "pull" . . . . . . . . . . . 9 3.3.3. Location configuration by "push" . . . . . . . . . . . 10 3.3.4. Location conveyance by value . . . . . . . . . . . . . 10 3.3.5. Location conveyance by reference . . . . . . . . . . . 10 3.3.6. Presence server . . . . . . . . . . . . . . . . . . . 10 4. Required Assurances . . . . . . . . . . . . . . . . . . . . . 11 4.1. Location Transmission . . . . . . . . . . . . . . . . . . 11 4.1.1. Location Mover . . . . . . . . . . . . . . . . . . . . 11 4.1.2. Rule Maker . . . . . . . . . . . . . . . . . . . . . . 12 4.1.3. Location Server . . . . . . . . . . . . . . . . . . . 12 4.1.4. Location Recipient . . . . . . . . . . . . . . . . . . 12 4.2. End-to-end distribution . . . . . . . . . . . . . . . . . 13 4.2.1. Location Generator . . . . . . . . . . . . . . . . . . 13 4.2.2. Viewer . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.3. Target . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Security Requirements . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Informative References . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Barnes, et al. Expires May 22, 2008 [Page 2]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007 1. Introduction Demand for location-based Internet applications, especially location- based Internet calling [I.D-ietf-ecrit-framework], has driven the creation of Internet protocols for communicating information about the location of Internet end hosts or other entities. Of interest, for example, are protocols for informing hosts of their own location (location configuration protocols), transmitting location information from one host to another (location conveyance protocols), and requesting location information from a server (location dereference protocols). The first goal of this document is to describe how location information is used by these protocols over its entire "life-cycle". This life-cycle begins when location information is introduced into an IP network via a location configuration protocol, continues through one or more transmission by way of location conveyance protocols (and dereference protocols, when conveyed by reference), and ultimately ends when the location is delivered to an application consumer. A model for the use of Internet protocols to transmit location information via a store-and-forward network of Location Servers has been described in RFC 3693 [RFC3693]. Privacy concerns and privacy- relevant security concerns are described in RFC 3694 [RFC3694]. This document extends the model of these previous documents to explicitly take into account the end-to-end properties of the system, and to address security mechanisms related to concerns other than privacy. The Location Objects (LO) described in RFC 3693 and RFC 3694 are usually encoded as XML documents in the Presence Information Data Format - Location Object (PIDF-LO) schema [RFC4119]. While the general trend in the IETF is to require that LOs be in this format, certain protocols do not use PIDF-LO, most notably the DHCP extensions to carry location in civic [RFC4776] or geospatial [RFC3825] format. In this document, such formats for location information are also regarded as LO formats, even though they do not comply with the requirements for LO formats in RFC 3693. The remainder of this document is structured as follows: After relevant terminology is introduced in Section [ref], Section [ref] describes an architecture for the end-to-end distribution of location over the Internet. In particular, this architecture describes a set of entities that work together to move location information from source to consumer. Based on the roles they play in the architecture, these entities may require certain assurances, and these are described in Section [ref]. Finally, the technical properties and mechanisms required to enable these assurances are Barnes, et al. Expires May 22, 2008 [Page 3]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007 reflected in a set of requirements for Geopriv security mechanisms. 2. Terminology 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 [RFC2119]. Most of the terms used in this document are defined in RFC 3693. New terms, and terms which have a different meaning than in RFC 3693, are described below. Location Mover: An entity that causes a location transmission to occur. It may do so by instructing a Location Server to transmit location to a Location Recipient (a "push"), or it may provide a Location Recipient a reference that it can use to request the location from a Location Server (a "pull"). Location Server: An entity that transmits location according to privacy policies. Location Generator: The entity that introduces a Location Object to the Internet. An LG may perform sighting (i.e., it may determine the location of a Target), or it may act as a relay from some non- Internet-connected location resource. Location by value: Location is represented by value when it is represented directly, as a data object containing location information. We say that a location object is represented by value even if the information it contains is encrypted. Location by reference: Location is represented by reference when it is represented indirectly, as a reference to another location datum (possibly another reference). For example, if a URL returns a PIDF-LO document when dereferenced, then that URL constitutes a representation of the PIDF-LO by reference. 3. An End-to-end Location Architecture In this section, we present an architecture for the end-to-end communication of location information. The overall pattern of transmissions involved in this communication is often complex and thus such systems are modeled as the composition of atomic building blocks. In Section 3.1 we describe a single location transmission, and the Barnes, et al. Expires May 22, 2008 [Page 4]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007 roles played by parties in such a transmission. A location transmission is an atomic unit that models a single movement of location information. In Section 3.2 we describe how multiple location transmissions can fit together within an end-to-end system and the global roles played by entities in such a composite system. Finally, in Section 3.3 we demonstrate how this model maps to common location use-cases such as location configuration and point-to-point location conveyance. 3.1. Structure of a Location Transmission Location transmission is the basic building block for policy- constrained location distribution. A single transmission occurs in three steps, illustrated in Figure 1: 1. A Rule Maker informs the Location Server about Privacy Rules governing the distribution of Location Objects. 2. A Location Mover requests that location be moved, either by directing the LS to transmit the location to the LR or by providing the LR with a reference by which it can request location from the LS. 3. The LS determines whether the transmission is permitted by the rules available to it, and if so, transmits location to the LR (possibly as the result of a request by the LR). Note that the location transmitted in step (3) may be represented directly, as an intelligible LO, or indirectly, as a reference to the LO. When the LS provides a reference, it is also acting as an LM in a second transmission, in which the LR uses the reference to obtain an LO from another LS. In the below, the distinction between these representations is not significant, and we refer to the transmitted datum as a Location Object regardless of whether it is directly or indirectly represented. Barnes, et al. Expires May 22, 2008 [Page 5]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007 +---------+ | LM | +---------+ | +---(2)--either/or-------+ | | V V +---------+ +---------+ | LS |------(3)---->| LR | +---------+ +---------+ ^ | (1) | +---------+ | RM | +---------+ Figure 1: A single location transmission There are four roles involved in this transaction, a Location Server (LS), a Location Recipient (LR), a Location Mover (LM) and a Rule Maker (RM). A single entity will commonly play multiple of these roles within a single transaction (see Section Section 3.3 for examples). The only two roles that are necessarily separate are that of the LS and the LR, for obvious reasons. Location Mover (LM) The Location Mover is the party who causes the location transmission to occur. The LM may accomplish this in one of two ways. Either the LM tells the Location Recipient how to "pull" the LO, or else it tells the LS how to "push" the LO. In the former case, the Location Mover would send the Location Recipient a reference to the Location Server and to the location information to be retrieved. In the latter case, the Location Mover would send the Location Server an identifier for the Location Recipient and an identifier for of the location information to sent. Rule Maker The Rule Maker is the party who produces the rules governing whether a Location Recipient is allowed to receive location information and what precision of location information a Location Recipient is allowed to receive. (Such rules are described in [ref:RFC4745] and [ref:draft-ietf-Geopriv-policy].) The Rule Maker may send rules directly to the Location Server, or the Location Server may receive the rules as part of a location object as per [ref:RFC4119]. Note that some transmissions may occur without a Rule Maker, in which cases the transmission is constrained only by policy contained in the LO itself. Barnes, et al. Expires May 22, 2008 [Page 6]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007 Location Server The Location Server is the party who possesses the location information at the beginning of the transmission. The Location Server receives rules governing the location information as received from the Rule Maker, as part of the location object containing the location information, or as part of its internal configuration. The Location Server is responsible for applying these rules and as such he may need to reduce the precision of the location information or terminate the location transmission if the Location Recipient is not authorized to receive the location information. After applying the appropriate rules, the Location Server sends the location information to the Location Recipient. Location Recipient The Location Recipient receives the location from the Location Server. If the Location Mover indicates that the location is to be pulled by the Location Recipient, then the Location Recipient may need to send a message to the Location Server requesting the location. 3.2. The End-to-end Model and Global Roles The life-cycle of a Location Object typically consists of multiple location transmissions. For example, location might first be acquired via a location configuration protocol (LCP) and then conveyed via a location conveyance protocol). This end-to-end distribution process can be described as a "chaining together" of the individual transmissions described above; different transmissions are connected by an entity that acts as an LR in one transmission and an LS in the next. This process is illustrated in Figure 2. Note that although Figure 2 depicts a single "path", a single LS may transmit location to multiple LRs over time; grouping these paths together forms a logical distribution tree, with the LG as the root node and Viewers as leaf nodes. . +----+ . +----+ . +----+ . | LM | . | LM | . | LM | . +----+ . +----+ . +----+ . / \ . / \ . / \ +----+----+ +----+----+ +----+----+ +----+--------+ | LG | LS |--->| LR | LS |--->| LR | LS |--->| LR | Viewer | +----+----+ +----+----+ +----+----+ +----+--------+ . | . | . | . +----+ . +----+ . +----+ . | RM | . | RM | . | RM | . +----+ . +----+ . +----+ Figure 2: End-to-end location distribution In addition to the roles within a particular location transmission, there are also three additional global roles within the larger Barnes, et al. Expires May 22, 2008 [Page 7]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007 composite system. As described in Section 3, a given party may need particular assurances based on the global role that it plays. Location Generator The Location Generator is the party who initially introduces location information into the Internet. The LG may be (but need not be) the entity that performs the sighting of the Target. The LG may be the same as the target when mechanisms such as GPS are used, but in many settings the location generator is a separate entity within the access network. Viewer The Viewer is the party who ultimately makes use of the location information; in particular, the Viewer does not transmit location further. The Viewer is the Location Recipient in the final location transmission. Target The Target is the party whose location is described by the location information. Although not explicitly included in the model above, every LO has a Target, and the Target will frequently play multiple roles in the distribution of related LOs. It is common for a party to play different roles within the different transmissions. For example, the Target might be the Location Recipient during location configuration, then act as Location Server when transmitting the LO to a presence server, then act as a Rule Maker by providing the presence server rules for further dissemination of the LO. In some cases, the Target may be a Location Generator or a Viewer; obviously, we assume that the roles of the LG and the Viewer are played by different entities. 3.3. Usage Scenarios for this Model In order to make the meaning of the above model clearer, this section desribes how several common use cases can be described using the model. In addition, we describe how the transmission model described in RFC 3693 maps into the model described above. 3.3.1. RFC 3693 model of transmission Section 4 of RFC 3693 depicts the relationships of the primary Geopriv entities, in which the Location Server acts as a relay between a Location Generator and a Location Recipient, with rules provided by a Rule Holder. In this document, we take a more limited view of three of these roles: Here an Location Server is simply an entity that transmits location (relying on a separate associated Location Recipient for input), an Location Generator is simply a distinguished Location Server, and Rule Holders are omitted from the discussion because they simply act as intermediaries for Rule Makers. The omission of Rule Holders is not meant to claim that Rule Holders Barnes, et al. Expires May 22, 2008 [Page 8]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007 do not exist (for instance, RMs may transmit rules to the LS via a store-and-forward network, in which the nodes would be RHs); however, they do not have application-level significance. In exchange for using these more limited roles, the single "T"-shaped diagram of RFC 3693 maps onto a chain of two transmissions, as illustrated in Figure 3 below. The first transmission is from the LG (in this case, just another LS) to the LR that acts as the receiving component of the Location Server (as defined in RFC 3693). The second transmission is from the LS acting as the sending component of the RFC 3693 Location Server to the LR, as dictated by rules supplied by the RM. Note that in these transmissions, the role of the LM is undefined; RFC 3693 starts from the assumption that the given interfaces exist, without giving explicit consideration to how they are established. ...... . ...... . LM . . . LM . ...... . ...... +-------------+ | LS | +----+----+ | +----+----+ | +----+ | LG | LS |--->| LR | LS |--->| LR | +----+----+ | +----+----+ | +----+ . +--------|----+ . . | ...... . +----+ . RM . . | RM | ...... . +----+ . Figure 3: The model of RFC 3693, Section 4 3.3.2. Location configuration by "pull" Location configuration protocols, such as HELD [I.D-ietf-geopriv-http-location-delivery], that require a device to specifically "pull" location can be modeled as a location transmission as follows: The LIS discovery mechanism is the Location Mover. The LIS discovery mechanism sends the endpoint the identity of the LIS, e.g. the HELD server. (Note that in this case the Location Mover need not send the identity of the location information to the endpoint, because the identity of the location information is implicit in the identity of the endpoint.) The endpoint is the Location Recipient and also the Target. Upon receiving the identity of the LIS, the endpoint makes an LCP query to the LIS requesting location. The LIS is the Location Server and in this case has previously been provisioned with rules by the Rule Maker. The LIS applies the rules and returns a location object to the endpoint. Barnes, et al. Expires May 22, 2008 [Page 9]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007 3.3.3. Location configuration by "push" Location configuration protocols, such as DHCP, that push location information to the endpoint can be modeled as a location transmission as follows. The network (i.e. a lower layer protocol) tells the LIS, e.g. the DHCP server, that an endpoint has connected to the network and provides the LIS with an identifier for the endpoint. (Note that again in this case the identity of the endpoint is implicitly the identity of the location information.) The LIS is the Location Server and in this case has previously been provision with rules by the Rule Maker. The endpoint is the Location Recipient and also the target. Upon learning the identity of the endpoint the LIS then sends the location information to the endpoint. 3.3.4. Location conveyance by value A protocol, such as SIP, that conveys a location object by value can be modeled as a location transmission as follows. The calling device is both the Location Mover and the Location Server. The calling device possesses a location object that contains the rules governing the location information. The called device is the Location Recipient. The calling device applies the rules within the location object and then sends the location object to the called device (e.g. in the body of a SIP INVITE). 3.3.5. Location conveyance by reference A protocol, such as SIP, that conveys a location object by reference can be modeled as a location transmission as follows. The calling device is the Location Mover and possesses a reference to location information stored on an LIS. The calling device sends the location reference, containing both the identity of the LIS and the identity of the location information, to the called party (e.g. in the header of a SIP INVITE). The called party is the Location Recipient. Upon receiving the location reference, the called party sends a dereference request, containing the identity of the location information, to the LIS. The LIS is the Location Server, and has been previously provisioned with rules by the Rule Maker. The LIS applies the appropriate rules for the location information and returns a location object to the called party. 3.3.6. Presence server The subscription to location information on a presence server can be modeled as a location transmission as follows. The presence subscriber is the Location Mover and also the Location Recipient. Through some out of band mechanism (e.g. a business card) the presence subscriber learns the identity of a presence server and the Barnes, et al. Expires May 22, 2008 [Page 10]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007 identity of a target whose presence is stored on the server. The presence subscriber sends a subscription request, containing the identity of the target, to the presence server. The presence server has previously been provisioned with rules by the Rule Maker (in this case, most likely the target). The presence server applies the rules and constructs a location object which it then sends to the presence subscriber. 4. Required Assurances Each of the entities in the above model has expectations about how the system works, which may or may not be valid in a given situation. Depending on the needs of the entities, they may require assurances that their expectations are valid in a given situation. The goal of Geopriv security and privacy mechanisms is to provide such assurances. In order to determine requirements for Geopriv security mechanisms, then, we need to understand the assurances required by participants in the architecture. 4.1. Location Transmission As described above, there are generally four logical roles in a single location transmission. In some cases, the same entity may play multiple roles within a transmission. In that case, the set of assurances required by that entity is the union of the assurances required by the roles it fulfills. 4.1.1. Location Mover The goal of the Location Mover is to effect the communication of an LO from the Location Server to the Location Recipient. Conversely, the LM may not wish to disclose other LOs, or to disclose any information to other recipients. Because the LM does not perform the transmission himself, he cannot receive direct assurances about these questions; he must trust the LS and the LR to carry out his instructions. Thus, the only direct assurance of value to the LM is that his instructions are faithfully communicated to their recipient (the LS or the LR), and that those instructions unambiguously direct the recipient to perform the action desired by the LM (including the application of appropriate security measures on the transmission). In the "push" scenario, the instructions provided to the LS must clearly identify the LR, and in the "pull" scenario, the instructions provided to the LR must clearly identify LS. In both cases, the instructions must clearly identify the LO to be transmitted and the manner in which it should be sent. Not all of these indications need to be explicit in the instructions; for instance, an LS that only distributes location via HTTPS does not need to be instructed to use Barnes, et al. Expires May 22, 2008 [Page 11]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007 HTTPS for every transmission. 4.1.2. Rule Maker The goal of the Rule Maker is tell the LS policies to apply to transmissions, and to ensure that the rules clearly specify how the LS should execute them. The first assurance of relevance to the RM is to assure that rules are faithfully transmitted to the correct destination: Since policy documents can themselves be sensitive, the RM must verify that they are delivered only to the LS it intends, i.e., it must authenticate the identity of the LS and verify that the authenticated identity belongs to the desired LS. And since changes to a policy document can affect many subsequent transmissions, the RM requires assurance that rules are not modified en route to the LS. Second, in order to assure that policy is correctly executed, the transmitted rules must define an unambiguous mapping from LOs to actions that the LS must perform. The RM is further assured that the rules will be executed when the LS can provide confirmation that it is able to process the supplied rules at the time that the RM transmits them. 4.1.3. Location Server The goal of the Location Server is to transmit location in compliance with relevant policy. Thus, the primary assurances the LS requires are related to the question of whether a given transmission is authorized by policy. The LS must determine whether the LR is authorized to receive location; when a transmission is by "push", it must also determine whether the LM is authorized to initiate a transmission. As a pre-requisite, the LS must also verify that policy is valid, i.e., that the Rule Maker is authorized to dictate policy. All of these authorization decisions require that the server authenticate the identities of the parties requesting access (e.g., to move or receive location, or to install policy). Note that the manner in which these authorization policies are installed on the LS and applied to specific transmissions is a matter of local configuration. 4.1.4. Location Recipient The goal of the Location Recipient is to acquire the LO intended by the LM. In general, this assurance can be decomposed into assuring that the LS is the one intended to deliver the LO and that the LO is faithfully transmitted from the LM to the LR; the LS is trusted by the LR to deliver the LO specified by the LM. In the "push" case, the LR may not have information about the LS prior to the transmission, so it must also trust that the LS delivering location was properly instructed to do so. In the "pull" scenario, the LM has Barnes, et al. Expires May 22, 2008 [Page 12]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007 told the LR which LS should be delivering the LO, so the LR can be assured that the LS that does transmit location is the proper one by authenticating the identity of the LS. In both cases, the LR requires assurance that the LO is not modified while en route between the LS and the LR. 4.2. End-to-end distribution In addition to the four transmission entities described above, we also consider three distinguished entities in an end-to-end distribution scenario. They require assurances about the entire distribution chain, or the entire distribution tree. 4.2.1. Location Generator The Location Generator is the Location Server at the root of the distribution tree. The LG thus offers the valuable service of acting as an Internet-accessible source of location information, and its primary interest is in controlling the use of this service, especially controlling access to it. In terms of the model, the LG is interested in controlling the set of Viewers that are able to interpret and use the LO. There are two basic approaches to acheiving this control: First, the LG may distribute LOs that are encrypted in such a way that only the Viewers that are authorized to access the location encoded in the LO. Second, the LG may distribute LOs in indirect representation, i.e., location references. Because these references are not valuable by themselves, the LG can give allow them to be distributed by parties that may not be authorized to access the location they refer to. In order for the Viewer to obtain the location referred to, it has to engage in a final transmission, in which the LG is the LS; as part of this transmission, the LG can verify that the Viewer is authorized to receive the location. 4.2.2. Viewer The Viewer is the ultimate consumer of a Location Object. As a consumer, the Viewer requires assurance that location information is available to it by value, and that that information be correct, in the sense that the location information describes the actual location of the indicated entity at the indicated time. (In some cases, the entity and time may be implicit). Viewers' access to location information by value is largely a deployment issue, related to Viewers' ability to provide authentication credentials to Location Servers, and to Location Servers' authorization policies. In most situations, it is not possible to verify the correctness of location directly. Rather, a Viewer can receive assurance that a location is correct by virtue of trust in the source of the location information. That is, Viewer can have more confidence in the correctness of an LO Barnes, et al. Expires May 22, 2008 [Page 13]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007 when it can verify that the location was provided by a source that the it trusts to provide correct location. As with LG access control, this verification can be done either through the object or through the LS that provides it. If the LO itself provides a verifiable assertion as to its origin, then the Viewer receives assurance about its correctness even if it receives the LO via an untrusted channel. On the other hand, if the LS that provides the LO is trusted to provide correct location, then the Viewer receives assurance about the LO's correctness even if the ultimate origin of the LO (i.e., the LG) remains unknown to the Viewer. 4.2.3. Target The interests of the Target are discussed at length in RFC 3693 and RFC 3694. The Target by itself has no technical involvement in the distribution process; in order to affect how its location is distributed, it must take on one of the roles described above. For instance, the Target will commonly act as an LS to explicitly control how location is transmitted, or as a Rule Maker to control distribution by a third-party LS. Much like the LG, the main concern of the Target is controlling access to its location. If the Target acts as an LS, then the assurances and mechanisms available to it are essentially the same as those available to the LG. 5. Security Requirements [RLB] In this section, we will define a taxonomy of location-relevant protocols, and set security requirements on them. As for the taxonomy, I tend to classify protocols according to which arrow they correspond to in Figure 1: o Policy Handling Protocols go between RMs and LSs (e.g., XCAP, common-policy) o Location Control Protocols go between the LM and the LS/LR (to many to list, we probably can't do much here) o Location Conveyance Protocols go between the LS and the LR (e.g., SIP Geolocation, HELD, Location dereference protocols) 6. Security Considerations The focus of this document is the security of location objects. As such, security concerns are discussed throughout. Barnes, et al. Expires May 22, 2008 [Page 14]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007 7. IANA Considerations This document makes no request of IANA. 8. Informative References [I.D-ietf-ecrit-framework] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling using Internet Multimedia", September 2007. [I.D-ietf-geopriv-http-location-delivery] Barnes, M., "HTTP Enabled Location Delivery", September 2007. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", February 2004. [RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat Analysis of the Geopriv Protocol", February 2004. [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", July 2004. [RFC4119] Peterson, J., "A Presence-based Geopriv Location Object Format", December 2005. [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", November 2006. Authors' Addresses Richard Barnes BBN Technologies 9861 Broken Land Pkwy, Suite 400 Columbia, MD 21046 USA Phone: +1 410 290 6169 Email: rbarnes@bbn.com Barnes, et al. Expires May 22, 2008 [Page 15]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007 Matt Lepinski BBN Technologies 10 Moulton St Cambridge, MA 02138 USA Phone: +1 617 873 5939 Email: mlepinski@bbn.com Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany 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 Barnes, et al. Expires May 22, 2008 [Page 16]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 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). Barnes, et al. Expires May 22, 2008 [Page 17]