Geopriv F. Anjum Internet-Draft D. Famolari Expires: August 17, 2006 A. Ghosh Telcordia Y. Ohba Toshiba H. Tschofenig Siemens February 13, 2006 Requirements for supporting Location-based Authorization Services within the PANA framework draft-anjum-pana-location-requirements-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 August 17, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The PANA protocol provides a means to authenticate clients in an IP network using cryptographic credentials. This document identifies scenarios where there may be a need for a client to provide location credentials, in addition to cryptographic credentials, to gain network access. This document also enumerates the requirements for PANA support of location based services. Anjum, et al. Expires August 17, 2006 [Page 1] Internet-Draft PANA location-based authorization February 2006 Table Of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Specification of Requirements . . . . . . . . . . . . . . 4 1.2. Problem Statement on location based authorization in PANA . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Usage scenarios for PANA clients supporting location-based authorization . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Simple location . . . . . . . . . . . . . . . . . . . . . 6 2.2. Secure location . . . . . . . . . . . . . . . . . . . . . 7 3. Location-based authorization requirements . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4.1. Threat models . . . . . . . . . . . . . . . . . . . . . . 11 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Anjum, et al. Expires August 17, 2006 [Page 2] Internet-Draft PANA location-based authorization February 2006 1. Introduction Location-based services are getting more and more common today. The range of these personalized services varies from determining the nearest place of interest to emergency services. Information about location is also expected to enable newer services. One such service that has not received much attention is a location-based authorization service [1]. In this case, an entity trying to get access to the network will not only have to prove its identity but also provide evidence of being in the right location. For example, a user might have to be present in his office in order to access certain services over the WLAN or to participate in a conference call. Similarly, a cafe might want to provide WLAN service only to customers sitting inside the building. As another example, a user might have to disable the picture-taking capability of their cell phone in specific premises, for example research labs of some company campuses, to prevent misuse. In addition, location information can also be expected to be used for validating some mobile e-commerce transactions. Thus, information about the location from where the transaction was initiated could be used along with other pieces of information for corroboration. Such services would attract the attention of adversaries whose objective is to try to deceive the localization system. An adversary could seek to achieve this by making use of special hardware, power variations, etc depending on the location technology being used. Given such an adversary, it would be necessary to design schemes that are secure and hence provide authentic location information in spite of the attempts by the intruder to cheat the localization system. We refer to localization techniques that achieve this objective as secure localization techniques and the applications that depend on these techniques as secure localization applications. While some of these secure localization applications can be enabled by GPS or similar technology, others may require a different solution. This is because GPS is costly, adding appreciably to the final cost of the solution, and insecure. Further, it is very easy to spoof GPS signals thereby causing the GPS receivers to report an incorrect location. In addition, with GPS the network will have to trust the end device to report the correct location. This would require the use of tamper proof GPS receivers. Tamperproof devices add extra expense to the device and are not foolproof [2]. It is important for the network to be able to securely determine the location of the user. There are two aspects to achieving this capability: 1) Technology to determine the location of the user such that the user is not able to spoof his location. We do not consider this Anjum, et al. Expires August 17, 2006 [Page 3] Internet-Draft PANA location-based authorization February 2006 aspect here. 2) Ability to convey information about the user location to the various entities in the network especially from the client device to the network. For example, PANA messages might have to be extended in order for information related to location to be conveyed securely from the PaC to the PAA. We focus on this aspect here in this draft. 1.1. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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 [10]. 1.2. Problem Statement on location based authorization in PANA PANA (Protocol for carrying Authentication for Network Access) defines an EAP [3] lower layer that uses IP between protocol end points. PANA enables link layer agnostic authentication between a PANA client (PaC) requiring network access and a PANA Authentication Agent (PAA) that authorizes network access. Authentication may be achieved by using any EAP authentication method. On successful completion of authentication, the PAA authorizes network access for the PaC. An Enforcement Point (EP) is responsible for managing per- packet filtering rules in the access network. The EP permits PaC related traffic once it receives the appropriate authorization from the PAA. Further information on PANA may be obtained in [4] and [5]. At the present time, PANA has been considered for authorizing network access based purely on cryptographic credentials in possession of the PaC. A AAA server may need to authorize network access for a PaC using information relayed by the PAA based not just on the PaC's identity but also it's geographical location. From this perspective it is necessary for the PaC to be able to securely provide authentic location information to the PAA in addition to its credentials for peer entity authentication. The PAA would then forward such information to the AAA server. The PAA can forward this information to the AAA server using an approach as proposed in [6]. Hence our focus is on the transfer of the location information between the PaC and the PAA. Incorporation of location information into the PANA protocol offers several additional benefits in terms of flexibility of their use and propagation. The PAA can, based on the policies received from the PaC, control the granularity of location information that is distributed to other network entities. For example, a AAA server may only need to know the country in which a PaC currently is located Anjum, et al. Expires August 17, 2006 [Page 4] Internet-Draft PANA location-based authorization February 2006 even though the PAA may have higher resolution location information available. PANA can support location-based services by supporting location-based authorization and location authentication. Location-based AuthoRization (LBAr) refers to authorization of a PaC based on location information. Location AuthentiCation (LAc) refers to the authentication of location information as a means to resist location spoofing. LBAr support may be incorporated into PANA messaging by enhancing the current protocol Essentially, there is a need to convey location information from the PaC to the PAA in a confidential and an authentic manner. This can be achieved by incorporating location information as data fields in payloads of selected PANA messages. It should be noted that LBAr is a continuous process and not a one-time authorization activity for PaCs that are mobile. While PaC mobility may or may not trigger a change in the access network being used, it would certainly cause a change in the physical location of the PaC. In this case the PAA would need to be aware of the location change without the commencement of a new access session since it would need to determine if the PaC was authorized to use the network or network service from its new location within the current access session. LAc might not require any extension to the PANA messaging beyond what is required for LBAr. The policies used by the PAA to authorize access for a PaC may either be transferred to the PAA from the PaC along with the location information, reside at the PAA itself, reside at a third party location authentication server or at some other location. This document does not specify the entity at which these policies reside. This document also does not discuss the rules associated with preserving the privacy of location information and instead points the reader to [7]. The actual format of the location information transferred by PANA messaging is outside the scope of this discussion and would be the subject of a later draft. The rest of this document is organized as follows. Section 2 describes some usage scenarios for location technologies in a PANA application environment. Section 3 enumerates the requirements for PANA support of location-based services. Section 4 discusses possible Security considerations for the incorporation of location-based authorization in PANA. Anjum, et al. Expires August 17, 2006 [Page 5] Internet-Draft PANA location-based authorization February 2006 2. Usage scenarios for PANA clients supporting location-based authorization 2.1. Simple location Many services require a simple, or basic, level of localization, for example, shopping services that provide coupons or sales offers to users that are in proximity to stores. In such cases, the level of granularity required from the localization technology may not be high. In addition, the security aspects might be needed (as for step 1 earlier). In such scenarios, the client will interact with a location provider's infrastructure to determine its location. Since such scenarios typically will not have stringent security requirements, the AAA infrastructure (which receives the location information via the PAA) will likely not need to verify the authenticity of the location information. +----+ | |--------+ | AP | | | | | +----+ | V +-----------------+ | +-----++-----+ | +-----+ | | || | | | | | | LC || PaC | |<---------->| PAA | | | || | | | | | +-----++-----+ | +-----+ +-----------------+ | ^ ^ | | | | +----+ | | | | | | | V | AP | | | +-----+ | |--------+ | | | +----+ +---------------->| EP | | | +-----+ Figure 1. Simple location based authorization The location technology used could be along the lines of PlaceLab [8] where the PaC is collocated with a location client. The location client computes location information using audible WLAN beacons. The location information will be transferred to the PaC which will, in turn, transfer them to the PAA during the PANA authentication process. The PAA will process the location information as part of the PANA Authentication phase and will communicate the results of its decision to the EP. These interactions are shown in Figure 1. Here Anjum, et al. Expires August 17, 2006 [Page 6] Internet-Draft PANA location-based authorization February 2006 information from multiple APs is used by an entity denoted as LC. The LC is collocated on the client device along with the PaC. The PaC obtains the location related information from the LC. Further, the PaC transfers this information securely to the PAA. The PAA could transfer this information further to the AAA server (this is not shown in the figure). The PAA would then instruct the EP based on the results of the processing at the AAA server. 2.2. Secure location +----+ | |--------+ | AP | | +-----+ | | | | | +----+ | | AS | V | | +-----------------+ +-----+ | +-----++-----+ | +-----+ | | | || | | | | | | | LC || PaC | |<---------->| PAA |-------------+ | | || | | | | | +-----++-----+ | +-----+ +-----------------+ | ^ ^ | | | | +----+ | | | | | | | V | AP | | | +-----+ | |--------+ | | | +----+ +---------------->| EP | | | +-----+ Figure 2. Secure location Many services require fast, accurate location capabilities. As a case example of secure localization we consider the case of providing access to a SCIF environment. SCIFs have very strict rules about what information can be accessed where, and often require that certain types of information only be available within the confines of the SCIF. In such a scenario, wireless radio coverage provided by an Access Point within the SCIF may leak outside the SCIF's physical boundaries making access to the SCIF's wireless network available outside of the SCIF's physical boundaries. Encryption and access restrictions may help prevent unauthorized users from gaining access to SCIF resources. However, what is needed is a mechanism to prevent authorized users from accessing the SCIF's wireless resources when they are not within the SCIF itself. For example, a user who is authorized within the SCIF may connect with a laptop or personal device to the SCIF's wireless network while they are inside the SCIF. Anjum, et al. Expires August 17, 2006 [Page 7] Internet-Draft PANA location-based authorization February 2006 In order to honor the information restrictions imposed by the SCIF, that same authorized user must be denied access to the network when they walk outside the SCIF, even if they maintain radio contact with the SCIF Access Point. Secure location scenarios require location information that is authenticable. For this purpose technologies along the lines of [9], [2] & [1] are applicable. In addition location verification capabilities are needed in the system. We do not focus on this aspect as described earlier. In addition, as mentioned earlier the protocol for transferring the information from the PAA to the Authentication Server is outside the scope of PANA, although it is conceivable that the Authentication Server supports a RADIUS/Diameter interface[6]. Interactions between a PaC and PAA involving an Authentication server for location information verification, are shown in Figure 2. Anjum, et al. Expires August 17, 2006 [Page 8] Internet-Draft PANA location-based authorization February 2006 3. Location-based authorization requirements We now enumerate the requirements for supporting location-based services using PANA. We establish the motivation behind each requirement as well as possible PANA extensions that could be used to meet it. As mentioned in the introduction, we believe that all the requirements can be met without extending the PANA protocol message set. The only probable extensions required would be to the message payloads in the form of additional data fields for carrying location information. R1. PAA must be able to obtain location information for a PaC. For the purpose of ascertaining the location of the PaC, it is essential for the PAA to receive the PaC's location information in some form. It is likely that the decision to admit the PaC will not be made at the PAA. Instead, the location information would be "passed-through" to an authentication server that would return the results of its decision in Boolean form. In addition, location information may not directly reflect the physical position of the PaC but may require a translation step. This translation step could also be undertaken by a third party service provider. Location information may be provided directly by the PaC. In this case, it is expected that the PaC may be collocated with a location module (a GPS receiver is an example of such a location module), which is responsible for generating the information. The transfer of the location information from the PaC to the PAA would be achieved by using standard PANA messages with possible payload extensions. Alternately, location information could be provided by a third party location provider as is the case for U-TDOA where a network entity determines handset location. In this case, the PAA would need to query the location provider for the PaC's location once the latter's identity is established. The actual messaging used in this case is outside the scope of this internet draft. R2. PAA must be able to determine changes in PaC location during a PANA session As a result of PaC mobility, it is possible for a PaC to move outside the authorized location space during the course of an active PANA session. To prevent such situations from happening, it should be possible for a PAA to determine any changes in PaC location during the course of a PANA session. PANA "Access Phase" messaging may be leveraged for this purpose. A request for updated location information could be transmitted Anjum, et al. Expires August 17, 2006 [Page 9] Internet-Draft PANA location-based authorization February 2006 in a PANA-Ping-Request message from the PAA to the PaC. In this case, the PaC could send updated information in a PANA-Ping-Answer message. Location information request frequency could be determined via policies in effect at the access network. Alternately, the PaC could proactively send out its location information without the need for explicit requests from the PAA. R3. PAA must be capable of terminating network access in case the PaC location is outside the authorized region In case a PaC is found to be outside the authorized location space during the course of an active PANA session, PANA "Termination Phase" messaging may be employed to end the PANA session. In this case the PAA should inform the EP to remove access privileges for the PaC. R4. The PaC must be able to send location information confidentially to the PAA. R5. The PAA should also be able to verify that the location information indeed originated at the claimed PaC. Anjum, et al. Expires August 17, 2006 [Page 10] Internet-Draft PANA location-based authorization February 2006 4. Security Considerations 4.1. Threat models Given that we focus on transmission of location based information, we need to ensure that the location information is not modified while in transit. This is ensured due to the fact that the entities that handle the location information are trusted entities. A related issue is that due to privacy and the reader is referred to [rfc3693] for a discussion on privacy considerations for location objects. There are other threats that we do not consider here but need to be addressed by the positioning technology. For example an adversary might desire to disrupt the location estimation process so that the system estimates the location of an honest user wrongly. Such an adversary can deploy a GPS simulator. In this case even though the actual user is honest, the GPS receiver at the user can be impacted due to use of the GPS simulator by the adversary. As a result, the honest user would possibly estimate a wrong location. Note that this is a problem with the positioning technology and we do not address this here. Anjum, et al. Expires August 17, 2006 [Page 11] Internet-Draft PANA location-based authorization February 2006 5. References [1] Denning, D. E., MacDoran, P. F., "Location-Based Authentication: Grounding Cyberspace for Better Security" Computer Fraud & Security, February 1996, Elsevier Science Ltd. [2] Pozzobon, O., Wullems, C., Kubik, K. "Trust your receiver? Enhancing location security" GPS World, Oct 2004. [3] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., Levkowetz, H. (Ed.), "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [4] Forsberg, D., Ohba,Y., Patil, B., Tschofenig, H., Yegin, A., "Protocol for Carrying Authentication for Network Access (PANA)", draft-ietf-pana-pana-10 (work in progress), July 2005. [5] Jayaraman, P., Lopez R., Ohba, Y., Parthasarathy M., Yegin A., "PANA Framework", draft-ietf-pana-framework-05 (work in progress), July 2005. [6] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., " Carrying Location Objects in RADIUS", draft-ietf-geopriv-radius-lo-04.txt (work in progress), July 2005. [7] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., Polk, J., "Geopriv Requirements", RFC 3693, February 2004. [8] LaMarca, A., Chawathe, Y., Consolvo, S., Hightower, J., Smith, I., Scott, J., Sohn, T., Howard, J., Hughes, J., Potter, F., Tabert, J. Powledge, P., Borriello, G., Schilit, B., "Place Lab: Device positioning using radio becons in the wild." In Proceedings of Pervasive 2005, LNCS. Springer-Verlag, May 2005. [9] Anjum, F., Pandey, S., Kim, B., Agrawal, P., "Secure localization in sensor networks using transmission range variation," 2nd IEEE International Conference on Mobile Adhoc and Sensor Systems pp. 195 -203, November 2005. [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Anjum, et al. Expires August 17, 2006 [Page 12] Internet-Draft PANA location-based authorization February 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Anjum, et al. Expires August 17, 2006 [Page 13]