Carrying Location Objects in RADIUS Hannes Tschofenig, Farid Adrangi, Avi Lior, Mark Jones

History IETF # 59: Two individual drafts on the subject: — IETF #60: The authors of the two drafts got together and wrote a new draft: Carrying Location Objects in RADIUS IETF #61: Two draft revisions —

Delivery Methods for Location Information Goals: Location Information must be available at the home AAA server Users privacy must be taken into consideration Why do you need the "users" location at the home AAA server? — Location-based authorization — Taxation (based on location) — Some people might use it for location based services 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 NAS AAA Start Auth. Phase RADIUS Access-Request + LO... multiple roundtrips... Access-Accept + Privacy Attr. Auth. Accept MN RADIUS Accounting Request + LO

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

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] Basic-Policy-Rules — Reuses basic authorization policies from [PDIF-LO] Extended-Policy-Rules — Points to full authorization policies [PIDF-LO] Location-Type Attribute — Classes of location types (from 'Coffee Shop' to 'Public Place')

Location-Information Attribute | Type | Length | Code | Precision | | Location-Info (0) Civil (1) Geospatial (0) NAS (1) AAA server (2) User (3) Network | LaRes | Latitude | Latitude | LoRes | Longitude | Longitude | AT | AltRes | Altitude | Altitude | Datum | | Countrycode | Civic address elements Civil Location Information Geospatial Location Information TLV elements: CAtype CAlength CAvalue Example:

Basic-Policy-Rules 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. — 'note-well': This field contains a URI with human readable privacy instructions.

Extended-Policy-Rules Attribute Ruleset reference: — The text field contains a reference to the policy rules. The full ruleset cannot be carried in RADIUS due to size considerations.

Location-Type Attribute Classes of location types — 0 Reserved — 1 Coffee Shop — 2 Hotel — 3 Airport — 4 Mall — 5 Restaurant — 6 Bus — 7 Library — 8 Convention Center — 9 School — 10 Office — 11 Airplane — 12 Train — 13 Ship — 14 Educational Institute — 15 Public Place — 16 Other Comment from Henning Schulzrinne: — Use RPID values (and therefore the same IANA registration)

Questions?

BACKUP Slides

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 client