Radius EXT M. Jones Internet-Draft Bridgewater Systems Corporation Expires: July 2, 2003 H. Tschofenig J. Cuellar Siemens January 2003 GEOPRIV support for RADIUS draft-jones-radius-geopriv-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 July 2, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Network access servers are increasingly capable of providing user and device location information to AAA servers. This enables the AAA server to make additional authorization decisions based on the location of the user or access device. The home or visited network may also use the location information for other purposes (e.g., acting as a location server). This document provides guidelines for the encoding and transport of location information using the RADIUS protocol which are compliant with the Geopriv requirements for security and privacy. Jones, et al. Expires July 2, 2003 [Page 1] Internet-Draft GEOPRIV support for RADIUS January 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Framework and Scenarios . . . . . . . . . . . . . . . . . . . 5 3.1 Location information about a network . . . . . . . . . . . . . 7 3.2 Location information about an end user . . . . . . . . . . . . 7 3.3 Visited and Home network as a Location Server . . . . . . . . 8 3.4 Default privacy-sensitive policy . . . . . . . . . . . . . . . 9 4. RADIUS Usage Scenarios . . . . . . . . . . . . . . . . . . . . 10 4.1 Home Network Access . . . . . . . . . . . . . . . . . . . . . 10 4.2 Visited Network Access . . . . . . . . . . . . . . . . . . . . 11 4.3 Visited Network Access via Broker . . . . . . . . . . . . . . 12 5. Location Information . . . . . . . . . . . . . . . . . . . . . 15 5.1 Civil Location . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2 Geospatial Location . . . . . . . . . . . . . . . . . . . . . 16 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 25 Normative References . . . . . . . . . . . . . . . . . . . . . 26 Informative References . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . 30 Jones, et al. Expires July 2, 2003 [Page 2] Internet-Draft GEOPRIV support for RADIUS January 2003 1. Introduction Location information needs to be protected against unauthorized access to preserve privacy of the owner of the location information. The GEOPRIV working group has defined a protocol-independent model for access to geographic information. The model includes a location generator (LG) that produces location information, a location server (LS) that authorizes access to location information, a location recipient (LR) that requests and receives information, and a rulemaker (RM) that provides policy rules to the LS which enforce access control policies on access to a target. The GEOPRIV working group provided mainly two results. [6] provides the building blocks for the Location Object (LO) itself which contains location information and authorization policies. Two policy rule namespaces have been defined. The first basic rule set, which can be found in [6], can restrict how long the receiver can retain location information and it can prohibit any further distribution. More sophisticated authorization policy rules can be attached to the LO itself (by value or by reference). Location server evaluate these rules to restrict access to location information. GEOPRIV does not reinvent a new location information format. Instead, a subset of GMLv3 is used to provide a rich and flexible mechanisms for representing location information.Section 5 and [6] provide more details on location information encoding using XML in GMLv3. [7] gives details on authorization policies. Network access servers are increasingly capable of providing user and device location information to AAA servers. This enables the AAA server to make additional authorization decisions based on the location of the user or access device. The home or visited network may also use the location information for other purposes (e.g. acting as a location server). The privacy issues discussed in GEOPRIV are especially applicable to the transport of Location Objects between administrative domains using the RADIUS protocol [5] . This document describes the types of location information available to RADIUS clients and servers. It also analyses the various RADIUS usage scenarios with a view to providing security and privacy recommendations for the transport of location information. Finally, the document provides recommendations for the encoding of location and rule set information in the RADIUS protocol. The GEOPRIV requirements [3] will be the guiding document for these recommendations. Jones, et al. Expires July 2, 2003 [Page 3] Internet-Draft GEOPRIV support for RADIUS January 2003 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 [1]. This document reuses the terminology of [3] for Geopriv specific terms such as location server (LS), location recipient (LR), target, using protocol, rule maker (RM) and location object (LO). Jones, et al. Expires July 2, 2003 [Page 4] Internet-Draft GEOPRIV support for RADIUS January 2003 3. Framework and Scenarios This section describes different models on how location information is retrieved and for which entity location information is requested. Requesting and using location information of a user certainly has privacy implications. In many cases the location information of the network might also reveal the current location of the user with a certain degree of precision depending on the mechanism used, to determine the location, update frequence, where the location was generated, size of the network and other mechanism (such as movement traces or interpolation). We distinguish the case where location information of the visited network is desired whereas the location information of the end host is requested. The latter case can be distinguished from the former by considering the usage of this information. If location information is used for a purpose related to a user then we think it is inappropriate to ignore privacy aspects. In some usage scenarios the network access authentication procedure can be tighly coupled with the transfer of location information. This easily allows to correleate the authenticated user identity and its location information. Jones, et al. Expires July 2, 2003 [Page 5] Internet-Draft GEOPRIV support for RADIUS January 2003 +------+ +-------------------+ AAA +-----------------+ | |Broker| | +----------+-----------+ +------+ +---------+------------+ | +---+--+ | | +--+---+ | | |Local | | | | Home | | | | AAA +--------+----------------------+------+ AAA | | | |Server| | | |Server| | | +---+--+ | | +------+ | | | | | | | Visited Network | | User's Home Network | | | | | | | +---+----+ | +----------------------+ | | Network| | +------+ Access +------+ | Server | +---+----+ | +---+----+ | Network| | Access | | Client | +---+----+ | O /|\ / \ User Figure 1: Framework Figure 1 shows the different entities participating the various scenarios and note that they might have multiple roles in the Geopriv architecture. For example, the location generator might be the network access client, the user, the local AAA server or another entity in the network. The location server at the local network might be co-located with the AAA server but might also be a physically separated entity. A future version of this document will include a discussion of a more fine-grain differentiation for location requests. The home AAA server is able to request the location object for a particular user or of the visited network. Two variants can be considered. First, the Location Object is requested implicitly, i.e., the Location Object is attached during the network authentication exchange. Second, the home AAA server requests the LO explicitly. This has implications on how a query has Jones, et al. Expires July 2, 2003 [Page 6] Internet-Draft GEOPRIV support for RADIUS January 2003 to be constructed (i.e., how does the home AAA server request the location object for a particular user). Currently, we assume that the Location Object is sent from the visited AAA server to the home AAA server during or after a successful the network access authentication procedure. Both RADIUS and DIAMETER have the ability to provide interim updates on network usage. Hence, this functionality can be used to periodically transmit uptodate location information. The interval of these updates is typically dictated by the home network when the session is authorized. 3.1 Location information about a network The home AAA server requests location information about the visited network itself. In some cases (with a large visited network) it might be difficult to imply the location of a particular user (at least with a certain granularity). GMLv3 provides mechanisms describe the irregular shape of a network. This scenario is useful particularly in cases where the network is non-stationary (such as trains, ships, busses) or where a relationship between the home network and the visited network is dynamically established and the visited network is, to some extend, not known to the home network. If a user is authenticated/authorized only once by the Home AAA server for the use of the entire visited network, the Home AAA server may want to know the extent of the visited network prior to authorizing the usage. It may even return an authorized shape such that re-authorization is required if the user moves outside the specified shape. From a privacy point of view this scenario is certainly simpler since the network is able to control disclosure of its own location information and is able to restrict its distribution (and its granularity). Still GEOPRIV is useful since both the location information format and mechanisms for authorization policy handling can be used. If location information is bundled with a particular user (or used in the context of a particular user) then the authors argue that privacy concerns are applicable. This leads us to the second usage scenario. 3.2 Location information about an end user The home AAA server requests (or automatically receives) the location object of a particular user. This assumes that the location of the Jones, et al. Expires July 2, 2003 [Page 7] Internet-Draft GEOPRIV support for RADIUS January 2003 user is known to the visited network with a certain precision. The exchange might be combined with the initial network access authentication request or even with a later service request. In the latter case it is possible that the target (i.e., user) was already able to transfer some authorization policies to the access network to prevent unlimited distribution of location information. In the former case it is difficult for the end host to provide some rules to the visited network. Additionally, it might even possible that the end host itself provides location information to the local network. From a protocol point of view this message exchange might be outside of scope of this document. However, the consequence of such an exchange is that the network is able to retrieve highly accurate information and also policy rules which might allow disclosure of location information in many ways. Note that the end host might also provide incorrect information (i.e., lie about its current location) to the visited network which can only be prevented to a certain extend. Rules can be included per-value or per-reference. In case that rules are provided per-reference then the local network MUST resolve the reference before responding to redistributing it. For the purpose of providing location information to the home network the end host acts as location generator (LG) and most likely as rule maker (RM) and the local network acts as a location recipient (LR) with regard to location information relevant for the local network itself. However, to provide location information to the home network the local network itself acts as a location server (LS). 3.3 Visited and Home network as a Location Server Although not immediately applicable to Radius as a using protocol for Geopriv, the authors think that this issue desires a short discussion. Both the visited and the home network might not be the final consumer of the location information itself. Once the infrastructure is deployed and useful applications are available there might be a strong desire to use location information for other purposes as well (such as location aware applications). Geopriv authorization rules are tailored for this environment as well. As described in previous sections no ideal protocol is available for communication between the end host and the visited network to obtain location information of the end host. If the location itself is known then the user would have to communicate policies for disclosure of location information. Geopriv does not mandate a particular mechanism for carrying policies other than with the Location Object itself (per value and per reference). Many different protocols might be used to create, update or delete policies at a LS in the visited network. PANA [8] might be a protocol for carrying location objects between Jones, et al. Expires July 2, 2003 [Page 8] Internet-Draft GEOPRIV support for RADIUS January 2003 the end host and the visited network or even for providing a URL to policies (the policies might be stored at the home network, for example). Since PANA does not provide confidentiality protection it is necessary to protect the Loation Object with S/MIME which might lead to IP fragmentation. If authorization policies itself should be delivered to the network then XCAP [10] could be used. The scenario for having the location server at the home network is much simple since a strong trust relationship between the user and the home network is available. With the subscription of the user default policies can be configured. 3.4 Default privacy-sensitive policy This section talks about the default configuration for distributing location objects. Two types of entities act as location servers in the configuration shown in Figure 1: Entity in the visited network (e.g., visited AAA server): In this scenario it might be difficult to have policies retrieved from the end host (or user). In this case we have to assume that the visited network does not allow unrestricted distribution of location information. Hence, as a simplification we can assume that per default only the home network is allowed to receive location information. Entity in the home network (e.g., home AAA server): An entity in the home network serves two purposes: First, it might be an ideal place for storing authorization policies and additionally it could store the user's location information for further distribution. In the latter case the home AAA server (or a similar entity) acts as a location server to respond to queries from location recipients. If the end host provides a location object then it might not always want to transport policies along with them. Instead it might be desireable to provide a reference to those object stored at the home location server. As a default policy we specify that the home network MUST NOT distribute the users location information for other. Per default MUST NOT distribute location information of a user to networks other than the user's home network. Jones, et al. Expires July 2, 2003 [Page 9] Internet-Draft GEOPRIV support for RADIUS January 2003 4. RADIUS Usage Scenarios 4.1 Home Network Access +----------------+ | Home Network | | | | +--------+ | | | Home | | | | AAA | | | | Server | | | +----+---+ | | | | | | | | +----+---+ | | | Network| | | | Access | | | | Server | | | +----+---+ | | | | +--------+-------+ | +----+---+ | Network| | Access | | Client | +--------+ O /|\ / \ User Figure 2: Home Network Access In Figure 2, the user is requesting access to his or her home network. The RADIUS protocol is used to communicate the user's identity and credentials from the NAS to the Home AAA Server. The NAS may also be in possession of location information at the time of authentication and this location information MAY be provided to the Home AAA Server in the Access-Request packet. If the NAS also determines the ruleset (or ruleset reference) which applies to the location information, it MUST forward it to the Home AAA server along with the location information. In this scenario, the NAS is considered to operate in the role of a Location Generator and NOT a Location Server. Consequently, RADIUS is NOT considered a 'Using Protocol' and the transport of the location and/or ruleset between NAS and Home AAA Server are not subject to the Jones, et al. Expires July 2, 2003 [Page 10] Internet-Draft GEOPRIV support for RADIUS January 2003 GEOPRIV security and privacy requirements. Note that Home AAA MAY also be capable of functioning as a Location Server but the protocol between such a Location Server and the Location Recipient is out of the scope of this draft. Even though RADIUS does not serve as a Geopriv using protocol it is still useful to reuse results of the Geopriv working group with regard to the location information format. Using GMLv3 prevents to reinvent a new location format. 4.2 Visited Network Access +----------------+ +----------------+ | Visited Network| | Home Network | | | | | | +--------+ | | +--------+ | | | Visited| | | | Home | | | | AAA +---+-----+---+ AAA | | | | Server | | | | Server | | | +----+---+ | | +--------+ | | | | | | | | | +----------------+ | +----+---+ | | | Network| | | | Access | | | | Server | | | +----+---+ | | | | +--------+-------+ | +----+---+ | Network| | Access | | Client | +--------+ O /|\ / \ User Figure 3: Visited Network Access In Figure 3, the user is attempting to access a partner network. The RADIUS protocol is used to communicate the user's identity and credentials from the NAS to the Visited AAA Server and subsequently onto the Home AAA Server. In this scenario, the Visited AAA Server can be considered as acting in the role of Location Server whether or Jones, et al. Expires July 2, 2003 [Page 11] Internet-Draft GEOPRIV support for RADIUS January 2003 not the location information is explicitly requested by the Home AAA Server. The Home AAA server is acting in the role of Location Recipient. If the Visited AAA Server has determined both the location and applicable ruleset, it MUST evaluate the ruleset prior to communicating the location information to the Home AAA. If the rules allow forwarding, the Visited AAA Server MUST forward the ruleset along with the location information to the Home AAA Server. If, however, the Visited AAA Server is unable to determine the applicable ruleset, it MUST advertise availability of the location information to the Home AAA Server and request the appropriate ruleset. If the Home AAA Server does not return the requested ruleset, the Visited AAA server MUST discard the location information. 4.3 Visited Network Access via Broker Jones, et al. Expires July 2, 2003 [Page 12] Internet-Draft GEOPRIV support for RADIUS January 2003 +----------------+ +----------------+ | Visited Network| | Home Network | | | | | | +--------+ | +--------+ | +--------+ | | | Visited| | | Broker | | | Home | | | | AAA +---+--+ AAA +--+---+ AAA | | | | Server | | | Server | | | Server | | | +----+---+ | +--------+ | +--------+ | | | | | | | | | +----------------+ | +----+---+ | | | Network| | | | Access | | | | Server | | | +----+---+ | | | | +--------+-------+ | +----+---+ | Network| | Access | | Client | +--------+ O /|\ / \ User Figure 4: Visited Network Access via Broker In Figure 4, the Visited and Home Network do not have a direct roaming agreement and so roaming is facilitated by an intermediary called a broker. The Broker AAA Server is responsible for routing AAA requests to the appropriate Home AAA Server and returning the results to the Visited AAA Server. The RADIUS protocol is used to communicate the user's identity and credentials from the NAS to Visited AAA Server to Broker AAA Server and finally onto the Home AAA Server. As in the previous section, the Visited AAA Server MUST NOT provide location information to the Broker AAA Server without first evaluating the rule set governing the usage of the information. If the Visited AAA Server has determined both the location and applicable ruleset, it MUST evaluate the ruleset prior to communicating the location information to the Broker AAA Server. If the rules allow forwarding, the Visited AAA Server MUST forward the ruleset along with the location information to the Broker AAA Server. In turn, the Broker AAA Server MUST also evaluate the ruleset prior to communicating the location information and ruleset to the Home AAA Jones, et al. Expires July 2, 2003 [Page 13] Internet-Draft GEOPRIV support for RADIUS January 2003 Server. If the Visited AAA Server is unable to determine the ruleset, it MUST advertise availability of the location information to the Broker AAA Server and request the appropriate ruleset. If the Broker AAA Server is able to determine the ruleset, it MUST return the ruleset to the Visited AAA Server on request. If the Broker AAA Server is unable to determine the ruleset, the Broker AAA Server MUST forward the advertisement of the availability of the location information to the Home AAA Server and request the appropriate ruleset. The Broker AAA server MUST NOT modify the ruleset returned by the Home AAA server prior to returning it to the Visited AAA server. On receipt of the ruleset, the Visited AAA Server MUST evaluate it and only forward the location information to the Broker AAA server if permitted by the ruleset. In turn, the Broker AAA Server MUST also evaluate the ruleset prior to forwarding the location information and ruleset to the Home AAA Server. The ruleset MUST always accompany the forwarded location information and MUST NOT be modified in transit. Jones, et al. Expires July 2, 2003 [Page 14] Internet-Draft GEOPRIV support for RADIUS January 2003 5. Location Information Geopriv defines both civil and geo-spatial location information which is useful in this context. Since GMLv3 does not provide civil location information the civil location format of [6] is used. 5.1 Civil Location Civil location is a popular way to describe the location of an entity. Using an unstructured (as a text string) or a custom format for civil location format is dangerous since the automatic processing capabilities are limited. The civil location format includes a number of fields, including the timezone, the country (expressed as a two-letter ISO 3166 code), and the administrative units of [11] A1 through A6. This designation offers street-level precision. The description below is only included for completeness. A more detailed description can be found in [6]. The following civil location elements are defined: +----------------------+----------------------+---------------------+ | Label | Description | Example | +----------------------+----------------------+---------------------+ | country | The country is | US | | | identified by the | | | | two-letter ISO 3166 | | | | code. | | | | | | | A1 | national | New York | | | subdivisions (state, | | | | region, province, | | | | prefecture) | | | | | | | A2 | county, parish, gun | King's County | | | (JP), district (IN) | | | | | | | A3 | city, township, shi | New York | | | (JP) | | | | | | | A4 | city division, | Manhattan | | | borough, city | | | | district, ward, chou | | | | (JP) | | | | | | | A5 | neighborhood, block | Morningside Heights | Jones, et al. Expires July 2, 2003 [Page 15] Internet-Draft GEOPRIV support for RADIUS January 2003 | | | | | A6 | street | Broadway | | | | | | PRD | Leading street | N, W | | | direction | | | | | | | POD | Trailing street | SW | | | suffix | | | | | | | STS | Street suffix | Avenue, Platz, | | | | Street | | | | | | HNO | House number, | 123 | | | numeric part only. | | | | | | | HNS | House number suffix | A, 1/2 | | | | | | LMK | Landmark or vanity | Low Library | | | address | | | | | | | LOC | Additional location | Room 543 | | | information | | | | | | | FLR | Floor | 5 | | | | | | NAM | Name (residence, | Joe's Barbershop | | | business or office | | | | occupant) | | | | | | | PC | Postal code | 10027-0401 | +----------------------+----------------------+---------------------+ Table 1 An example of a civil location XML fragment is shown below: US NJ Bergen Leonia Westview 5.2 Geospatial Location Geospatial location information is purely based on the capabilities offered by GMLv3. Jones, et al. Expires July 2, 2003 [Page 16] Internet-Draft GEOPRIV support for RADIUS January 2003 The Geography Markup Language (GML) as defined by OASIS provides powerful capabilities and is a flexible system for modelling topologies and for describing the location of an object. GML makes use of XML and [6] uses the 'feature.xsd' schema. Location information based on GML is only one information element within PIDF-LO (defined in [6]). Location information is, as a 'location-info' element, encapsulated within the XML-based Presence Information Data Format (PIDF) (see [9]) which provides additional information such as a 'timestamp' element which shows the creation time of the PIDF document or the 'presence' element pointing to the URI of the entity whose location information the PIDF object describes. Subsequently we provide some examples for location information. These examples are meant to illustrate the capability of GMLv3 'feature.xsd'. The first example of a geospatial location XML fragment with the 'gml:Envelope' element. The Envelope element allows to define pairs of positions with opposite corners in arbitrary dimensions. 140. -35. 1. 33. The second example shows the 'gmL:EnvelopeWithTimePeriod' element which is an Envelope element that includes also a temporal extent. Including a time period is useful to indicate the duration in which the indicated location is valid. 12 22 2002-11-25T13:20:20 2002-11-25T13:25:20 The next few examples show more sophisticated structures such as the Jones, et al. Expires July 2, 2003 [Page 17] Internet-Draft GEOPRIV support for RADIUS January 2003 'gml:Polygon' or the 'gml:LinearRing' element. A LinearRing is defined by four or more coordinate tuples, with linear interpolation between them; the first and last coordinates must be coincident. A Polygon is a special surface that is defined by a single surface patch. The boundary of this patch is coplanar and the polygon uses planar interpolation in its interior. It is backwards compatible with the Polygon of GML 2, GM_Polygon of ISO 19107 is implemented by PolygonPatch. 1 1 2 2 3 3 4 7 10,10 20,10 30, 10 30,20 10,20 10,10 Please note that the geographic position might be indicated using different coordinate reference systems. GMLv3 defines a number of commonly used onces but allows the system to be extended to support other reference systems. Encoding of location information within the 'gml:LocationString' element, which is a member of the locator attribute in the 'gml:Location' element, MUST NOT be used within Geopriv. Encoding of unstructured location information as a opaque string prevents interoperatability and makes automatic processing difficult. If this type of location information is desired then civil location information should be used instead (see Section 5.1). Jones, et al. Expires July 2, 2003 [Page 18] Internet-Draft GEOPRIV support for RADIUS January 2003 6. Example This section provides a complete example of location information based on PIDF [9] and PIDF-LO [6] including a basic ruleset (defined in PIDF-LO). Please note that the namespaces currently not yet registered and therefore we point to local files. An example with the more flexible authorization rules as defined with [7] will be provided in a future version of this document. US New York New York Broadway 123 Suite 75 10027-0401 yes 2004-06-23T04:57:29Z 2003-06-22T20:57:29Z Jones, et al. Expires July 2, 2003 [Page 19] Internet-Draft GEOPRIV support for RADIUS January 2003 The "entity" XML element which is part of every PIDF document signifies the URI of the entity whose presence the document describes. This value of this attributes indicates the target of that location information. The "tuple id" element uniquely identify the PIDF segment which allow easy tracking over time. The "timestamp" element designates the time at which the PIDF document was created and it corresponds to the sighting time as stated in requirement 2.7a of [3]. Based on the description in Section 5 it can be seen that civil location is embedded within the PDIF-LO and PIDF document. PIDF provides elements (such as timestamp) and also contains XML elements offered by PIDF-LO (for example the basic authorization rules 'retention-expiry' and 'retransmission-allowed'). PIDF-LO offers support for civil and gespatial location information. Jones, et al. Expires July 2, 2003 [Page 20] Internet-Draft GEOPRIV support for RADIUS January 2003 7. Packet Formats In a previous section, it was stated that the Visited AAA MUST NOT forward the location information to the Broker or Home AAA prior to evaluating the governing rule set. This is accomplished by the Visited AAA including a RuleSetRequest attribute in the RADIUS Access-Request packet. The value of this attribute can be used to indicate whether the originator is capable of processing a RuleSet and/or RuleSet reference. A LocationOriginatorRealm attribute is also included in the RADIUS Access-Request in order to identify who is requesting the RuleSet. The RuleSet or RuleSet reference is returned to the Visited AAA in either an Access-Accept or Access-Reject. It is returned in an Access-Accept if the location is NOT required by the Home AAA in order to complete the authorization for the session. It is returned in an Access-Reject if the location is required by the Home AAA in order to complete the authorization for the session. In the later case, the Visited AAA MUST resubmit the Access-Request after evaluating the RuleSet. +-------------------------+---------+---------+--------+--------+ | Attribute Name | Type | Request | Accept | Reject | +-------------------------+---------+---------+--------+--------+ | LocationOriginatorRealm | text | 0-1 | 0 | 0 | | | | | | | | RulesetRequest | integer | 0-1 | 0 | 0 | | | | | | | | LocationObject | text | 0-1 | 0 | 0 | | | | | | | | RuleSet | text | 0-1 | 0-1 | 0-1 | +-------------------------+---------+---------+--------+--------+ Table 2 o 0 This attribute MUST NOT be present in packet. o 0+ Zero or more instances of this attribute MAY be present in packet. o 0-1 Zero or one instance of this attribute MAY be present in packet. o 1 Exactly one instance of this attribute MUST be present in packet. TBD: Add packet size considerations. Jones, et al. Expires July 2, 2003 [Page 21] Internet-Draft GEOPRIV support for RADIUS January 2003 TBD: Add attribute descriptions, encodings and types. TBD: Need IANA considerations section for new attribute types. Jones, et al. Expires July 2, 2003 [Page 22] Internet-Draft GEOPRIV support for RADIUS January 2003 8. Security Considerations The Geopriv requirements draft [3] addresses the minimal security protection required for the Location Object: Mutual end-point authentication, data object integrity, data object confidentiality and replay protection. These security properties are implemented via S/MIME and between elements. Protection for the LO includes any attached authorization rules. To capture the different scenarios we need to address them individually: If location information of the visited network is requested by the home network then the visited network acts as a location server (LS) and as a location generator (LG). As such the visited network is able to restrict the distribution of location information. If location information of the user is requested by the home network then the extensions to RADIUS defined in this draft suggest to use it as a using protocol. The protocol capabilities make RADIUS a non-classic using protocol since the initial network access authentication procedure might serve the purpose of attaching location information to the exchange. Additionally, RADIUS can be used to request location information periodically to keep the Location Server at the home network uptodate with the current location of the end user and its movement patterns. If location information (either of the user, visited network or home network) is requested then the results of Geopriv are applicable. Although this communication exchange is not directly applicable for Radius itself it is useful to consider it in the larger context of privacy considerations. Protection needs to be protected in two fashions. First, it is necessary to use authorization policies to prevent the unauthorized distribution of location information. Second, it is necessary to fulfill the security requirements of the Geopriv requirements draft. These requirements are inline with the Geopriv threats draft (see [2]). [6] proposes S/MIME to protect the Location Object against modifications and against eavesdropping. To provide mutual authentication confidentiality protection and a digital signature is necessary. Furthermore, to offer replay protection a gurantee of freshness is necessary (for example, based on timestamps). The security of S/SIME is based on public key cryptography which raises some performance and deployment questions. Encryption requires that the local AAA server knows the recipients (i.e., home AAA servers) public key. Some sort of public key infrastructure is Jones, et al. Expires July 2, 2003 [Page 23] Internet-Draft GEOPRIV support for RADIUS January 2003 therefore required to obtain the public key (at the visited network) and to verify the digital signature (at the home network). Providing per-object cryptographic protection is, both at the home and at the visited network, quite expensive. To overcome this limitation an alternative approach is suggested. Two security mechanisms are proposed for RADIUS: o [5] proposes the usage of a static key which is not appropriate for protection of location information due to the missing dynamic key management and absent confidentiality protection. If no authentication, integrity and replay protection between the participating entities are provided then an adversaries can spoof and modify transmitted AVPs. o RADIUS over IPsec [4] allows to run standard key management mechanisms, such as KINK, IKE and IKEv2, to establish IPsec security associations. Confidentiality protection MUST be used to prevent eavesdropper gaining access to location information. Confidentiality protection is not only a property required by this document, it is also required for the transport of keying material in the context of EAP authentication and authorization. Hence, this requirement is, in many environments, already fulfilled. Mutual authentication must be provided between the local AAA server and the home AAA server to prevent man-in-the-middle attacks. This is another requirement raised in the area of key transport with RADIUS and does not represent a deployment obstacle. The performance advantages a superior compared to the usage of S/MIME and object security since the expensive authentication and key exchange protocol run needs to be provided only once (at for a long time). Symmetric channel security with IPsec is highly efficient. Since IPsec protection is suggested as a mechanism to protect RAIDUS already no additional considerations need to be addressed beyond those described in [4]. IPsec protection therefore seems to be adequate. Where an untrusted AAA intermediary is present, the Location Object MUST NOT be provided to the intermediary. This can be avoided by use of re-directs or by using S/MIME encryption. Jones, et al. Expires July 2, 2003 [Page 24] Internet-Draft GEOPRIV support for RADIUS January 2003 9. Open Issues This section lists some open issues which have been identified while working on this approach: o The size of the Location Object might be large when encoded in XML. A discussion of possible approaches for 'compressing' the location object needs to be provided in a future version of this document. o Tentative open issue: Packet formats o DIAMETER is also a good (or even a better) candiate to carry Location Object as described in this document. The authors decided to start with RADIUS but there are not reasons why the same mechanism should not be supported by DIAMETER. Jones, et al. Expires July 2, 2003 [Page 25] Internet-Draft GEOPRIV support for RADIUS January 2003 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [2] Danley, M., "Threat Analysis of the geopriv Protocol", draft-ietf-geopriv-threat-analysis-01 (work in progress), September 2003, . [3] Cuellar, J., Morris, J., Mulligan, D., Peterson, D. and D. Polk, "Geopriv requirements", draft-ietf-geopriv-reqs-04 (work in progress), October 2003, . [4] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [5] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [6] Peterson, J., "A Presence-based GEOPRIV Location Object Format", draft-ietf-geopriv-pidf-lo-00 (work in progress), January 2004, . [7] Tschofenig, H., Morris, J., Cuellar, J., Polk, J. and H. Schulzrinne, "Policy Rules for Disclosure and Modification of Geographic Information", draft-ietf-geopriv-policy-00 (work in progress), November 2003, . Jones, et al. Expires July 2, 2003 [Page 26] Internet-Draft GEOPRIV support for RADIUS January 2003 Informative References [8] Forsberg, D., "Protocol for Carrying Authentication for Network Access (PANA)", draft-ietf-pana-pana-02 (work in progress), October 2003, . [9] Sugano, H. and S. Fujimoto, "Presence Information Data Format (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003, . [10] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-01 (work in progress), October 2003, . [11] Schulzrinne, H., "DHCP Option for Civil Location", draft-ietf-geopriv-dhcp-civil-00 (work in progress), July 2003, . Authors' Addresses Mark Jones Bridgewater Systems Corporation 303 Terry Fox Drive Ottawa, Ontario K2K 3J1 CANADA EMail: mark.jones@bridgewatersystems.com Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany EMail: Hannes.Tschofenig@siemens.com Jorge R. Cuellar Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany EMail: Jorge.Cuellar@siemens.com Jones, et al. Expires July 2, 2003 [Page 27] Internet-Draft GEOPRIV support for RADIUS January 2003 Appendix A. Contributors Add your name here. Jones, et al. Expires July 2, 2003 [Page 28] Internet-Draft GEOPRIV support for RADIUS January 2003 Appendix B. Acknowledgments This document is partially based on the discussions within the IETF GEOPRIV working group. Some parts of this document are based on other Geopriv documents (for obvious reasons). For editorial reaons some paragraphs are included in this draft but might be replaced by a reference in a future version. The authors thank Henning Schulzrinne, James Polk and John Morris for their work they have done in the Geopriv working group. Henning additionally provided the civil location content found in this draft. Furthermore, we also have to thank Allison Mankin , Randall Gellens , Andrew Newton , Ted Hardie , Jon Peterson for their time discussing a number of details with us. It was fun to work with them. Finally, we would like to thank Hongkun Jiang for this assistance with GMLv3. Jones, et al. Expires July 2, 2003 [Page 29] Internet-Draft GEOPRIV support for RADIUS January 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Jones, et al. Expires July 2, 2003 [Page 30] Internet-Draft GEOPRIV support for RADIUS January 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jones, et al. Expires July 2, 2003 [Page 31]