Internet DRAFT - draft-anjum-pana-location-requirements
draft-anjum-pana-location-requirements
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]
