Carrying Location Objects in RADIUS <draft-tschofenig-geopriv-radius-lo-00.txt> Hannes Tschofenig, Farid Adrangi, Avi Lior, Mark Jones

RADIUS / Geopriv A quick reminder ... Location Objects are attached to RADIUS messages Location based authorization and taxation possible at home AAA server. RADIUS Access Network AAAL AAAH Home Network RADIUS AP IEEE 802.1x Mobile Node Figure 1: Example Network Topology

What happened since the last IETF meeting? Two presentations have been given at the last IETF meeting: <draft-adrangi-radiusext-location-information-00.txt> <draft-jones-radius-geopriv-00.txt> The authors of the two drafts got together and wrote a new draft: Carrying Location Objects in RADIUS <draft-tschofenig-geopriv-radius-lo-00.txt>

Delivery Methods for Location Information Goal: Location Information must be available at the home AAA server Two means to deliver Location Information to the AAAH: Authentication/Authorization Phase Delivery Mid-session Delivery

Delivery Methods for Location Information Authentication/Authorization Phase Delivery MN NAS AAA Start Auth. Phase RADIUS Access-Request + Loc-Attr. ... multiple roundtrips ... Access-Accept Auth. Accept RADIUS Accounting Request + Loc-Attr.

Delivery Methods for Location Information Mid-session Delivery NAS AAA COA + Service-Type "Authorize Only" COA NAK + Service-Type "Authorize Only" + Error-Cause "Request Initiated" Access-Request + Service-Type "Authorize Only" + Loc-Attr. Access-Accept Legend: Change of Authorization (CoA) message [RFC3576]

New RADIUS Attributes Reusing existing Geopriv work! Operator-Name Attribute This attribute contains an operator name which uniquely identifies the ownership of an access network. Location-Information Attribute Civil Location Information Format [ietf-geopriv-dhcp-civil] Geospatial Location Information Format [RFC3825] Policy-Information Attribute Reuses basic authorization policies from [PDIF-LO] Location-Type Attribute Classes of location types (from 'Coffee Shop' to 'Public Place') Billing-Description Attribute Unstructured text to be printed on the users bill

Location-Information Attribute (0) NAS (1) AAA server (2) User (3) Network Location-Information Attribute (0) Civil (1) Geospatial 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Code | Precision | | Location-Info ... Civil Location Information 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Countrycode | Civic address elements ... Geospatial Location Information TLV elements: CAtype CAlength CAvalue Example: <3(city), 6, Munich> 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LaRes | Latitude + | Latitude | LoRes | Longitude + | Longitude | AT | AltRes | Altitude + | Altitude | Datum |

Policy-Information Attribute Fields of the 'usage-rules' element defined in [PIDF-LO]: 'retransmission-allowed': '0' = Recipient is not permitted to share the enclosed Location Information '1' = Recipient is allowed to share Location Information with other parties. 'retention-expires': Absolute date at which time the Recipient is no longer permitted to possess the location information. 'ruleset-reference': This field contains a URI that indicates where a fuller ruleset of policies related to this object can be found.

Privacy Considerations Eavesdropping Threat: Eavesdropper learning Location Information + NAI Assumption: NAI reveals true user identity (might not be the case for some EAP methods) Solution: Use IPsec ESP between AAA servers Already required for key transport Cannot protect against entities participating in the signaling exchange (e.g., AAA server) itself => no true "end-to-end" security

Privacy Considerations Home AAA server acts as Location Server Scenario: Home AAA server retrieves location information and wants to use it for location-based services. Typically no problem since User has a strong trust relationship with home operator based on a contract. Authorization policies can be provided to the home AAA server (or the home network) before the protocol execution starts.

Privacy Considerations Visited AAA server acts as Location Server (1) Scenario: Visited AAA server collects and distributes location information of attached users. The same is applicable to AAA brokers User might not even allow location information to be forwarded to home network Problem: End host and visited network typically shares not trust relationship. Network access authentication procedure is executed to dynamically establish the trust relationship and to establish session keys. These keys are available after successful authentication and authorization. Successful authentication and authorization might require location information

Privacy Considerations Visited AAA server acts as Location Server (2) Approach 1: Use EAP method with active user identity confidentiality Problem: The choice of an EAP method is not only user driven Approach 2: Mandate default policy Problem: Will it be considered by all hot spots? Approach 3: Authorization policies are provided by the home AAA server - possible for mid-session delivery Problem: Addresses only some problems Approach 4: User provides authorization rules to visited network Problem: Securing the LO/Rules is difficult (key management problem) Existing protocols due not support this functionality (see EAP, PANA) Not a RADIUS problem

Outside the Scope Protocols executed between end host and NAS (e.g., EAP) Example: End host providing location information to RADIUS server

Next Steps / Open Issues Should this document become a working group item in the Geopriv working group? Technical issues to add for the next draft version: Scenarios need more text Interworking with DIAMETER needs to be described Discussion on the privacy issues Comments are appreciated!

Questions?