1. Policy Rules for Disclosure and Modification of Geographic Information ( draft-ietf-geopriv-policy-00.txt ) Authors: H. Schulzrinne J. Morris H. Tschofenig J. Cuellar J. Polk

2. Permissions and Rules Henning Schulzrinne

3. IETF#58 - Geopriv WG History Design team created after the Vienna IETF (IETF#57) Various drafts were used as input. Discussions lead to a draft which was presented at the Geopriv Interim Meeting in Washington (Sept. 2003): http://www.tschofenig.com/geopriv/Interim2003/ Draft includes — Geopriv interim meeting discussions & decisions — Content of previous drafts such as

4. IETF#58 - Geopriv WG Architectures for (geo) information access Claim: all using protocols fall into one of these categories Presence or event notification — “circuit-switched” model — subscription: binary decision Messaging — email, SMS — basically, event notification without (explicit) subscription — but often out-of-band subscription (mailing list) Request-response — SIP, RPC, HTTP; also DNS, LDAP — typically, already has session-level access control (if any at all) Presence is superset of other two

5. IETF#58 - Geopriv WG Presence/Event notification Three places for policy enforcement — subscription  binary only policy, no geo information subscriber may provide filter  could reject based on filter (“sorry, you only get county-level information”)  greatly improves scaling since no event-level checks needed — notification  content filtering, suppression of all or parts only policy, no geo information — third-party notification e.g., event aggregator can convert models: gateway subscribes to event source, distributes by email both policy and geo data

6. IETF#58 - Geopriv WG Presence model subscription policy event generator policy subscriber filter rate limiter change to previous notification? for each watcher subscriber (watcher) SUBSCRIBE NOTIFY

7. IETF#58 - Geopriv WG Protocols Rule Updates XCAP, WebDav, FTP, etc. Rule Holder Location Server Location Recipient Location Generator Policies Location Objects of Targets Location Requests / Responses 'Using protocols' (e.g., SIP, HTTP) Location Updates Watcher = Location Recipient Presentity = Target

8. IETF#58 - Geopriv WG Architectural Assumption Distributed Policies Decision at Vienna IETF to have two „namespaces“ a) Simple policies b) More complex policies (a) is attached to the location object (b) might either be attached to the location object or somewhere external (e.g., location server) Transformation policies: (b) modifies (a) Multiple location server along the LO transmission path (or "What is the end?"): — Applying policies in an iterative procedure should only add permissions. → Additive permissions

9. IETF#58 - Geopriv WG Policy rules There is no sharp Geopriv boundary Presence contains other sensitive data (activity, icons, …) and others may be added Example: future extensions to personal medical data — “only my cardiologist may see heart rate, but notify everybody in building if heart rate = 0” Thus, generic policies are necessary

10. IETF#58 - Geopriv WG Goals Relational table representation Permit only Additive permissions Upgradeable Versioning support Protocol-independent No false assurance

11. IETF#58 - Geopriv WG Non-Goals No queries No external references No regular expression No all-except conditions No repeat times

12. Changes and Open Issues Hannes Tschofenig

13. IETF#58 - Geopriv WG Logging Need for logging functionality has been raised in [Core] draft. Currently not provided. Realization simple but there are some problems: — If policies are attached to the LO then the RM might not know where the log files are stored. — Interaction with retention mechanism. More granularity might be required. Logging on a per-rule basis or "target-wide"/ "system-wide"?

14. IETF#58 - Geopriv WG Encryption It was decided that Geopriv protects the Location Object using S/MIME (application-layer security) This issue addresses whether encryption (+ info about encryption) should be applied on a per-rule or per-system basis. Some further issues deserve attention such as: — What happens if the public key is not known for the recipient? — What encryption technique should I use? — Should an identity be provided within the rule? — What happens if this identity specifies a SIPS URI (i.e., requiring that the request be via SIP-over-TLS) and the flag is not set, should it be refused? — If encryption is specified and the request was HTTP (not HTTPS), should the request be refused?

15. IETF#58 - Geopriv WG Identities & Authentication Types Several approaches have been mentioned to implement "Permission to disclose only to someone presenting a specified key" behavior. — XCAP Authz: and with SIP specific authentication mechanisms such as None, TLS, Digest, SMIME and P-Asserted-ID. — Authentication level in previous geopriv draft. Current draft dropped concept. Reason: — Practical problems — Difficult to provide proper meaning — Difficult to understand for end-user

16. IETF#58 - Geopriv WG Notifications Require notice to the rule maker if location is provided Difficult if you don't specify how. Currently there is no such mechanism define in Geopriv although many protocols support event notifications: — SIP, Jabber, SOAP events, email, some kind of RPC mechanism, an HTTP request to a specific address, syslog, etc. Details (such as content) need to be worked out. DoS attacks need to be addressed.

17. IETF#58 - Geopriv WG Naming Currently, defines protocol-specific identities, rather than generic ones Some protocols (SIP, XMPP, …) naturally have user identities in URIs — sip:alice@example.com — ftp:hgs:pw@ftp.example.com May not be the same as ID used to authenticate (e.g., HTTP/SIP Digest identity) — one authentication identity may allow for multiple protocol (e.g., SIP) identities No obvious way to encode for HTTP — needs: host, realm (?), username — fake: http:alice@www.example.com — new URI scheme —  all ugly Probably need to define this for each using protocol

18. IETF#58 - Geopriv WG Domains and Individuals Currently, only identities represented as URIs XCAP has notion of domain match, e.g., sip:example.com Not all authentication systems have notion of user@domain, but many do in practice. Somewhat complicates matching, but otherwise no architectural implications Structure of the identity needs to be known for matching.

19. IETF#58 - Geopriv WG Exceptions Exceptions only useful if domains (or groups) allowed — domains: probably most useful for mid-size organizations — small organizations can enumerate — really large organizations unlikely (give access to all my 753,000 fellow postal employees?) Two kinds of exceptions: — atomic = always part of the same rule in particular, must be very careful about replacing just exception element  temporarily unsafe — override = different rule, overrides more general rule Override breaks additive model — privacy-unsafe if rule cannot be accessed

20. IETF#58 - Geopriv WG Exceptions, cont’d. Atomic exceptions simply limit matching and are probably ok Need to be sure we understand cases like: — Rule 1: example.com except alice@example.com — Rule 2: example.com except bob@example.com What permissions does Bob get? — If ‘Rule 1’, easy.

21. IETF#58 - Geopriv WG Relationship to XCAP XCAP  transport (HTTP) + rules + manipulation GEOPRIV has more general model: — carried in LO  may not be HTTP — no requirement that RM-LS interface is HTTP Tying rules and transport together seems unnecessary

22. IETF#58 - Geopriv WG Default Behavior (1/2) Default behavior: What has to be assumed for omitted values (i.e., for values how appear as 'NULL' values in an attribute of row). Default behavior specified for — Conditions and for — Permissions (Transformations) Differentiation seems to be necessary between — Attributes whose removal may lessen privacy (the R/D/microwave flags) and — Attributes whose removal can only increase privacy (location objects). Seems to be a technical issue only which requires further thoughts.

23. IETF#58 - Geopriv WG Default Behavior (2/2) Example Figure 1: Policy ConditionsActions/Transforms Target-IDLR-IDD-FlagCivil-Location tedallisonFALSEcity ted*TRUEcountry D-FlagCivil-Location TRUEcity Figure 2: Result of a query by LR "allison" for target "ted" Rule evaluation might lead to a counter-intuitive result. Needs to be fixed.

24. Questions?