1 Role of Authorization in Wireless Network Security Pasi Eronen Jari Arkko November 3, 2004 This document has been produced partially in the context of the Ambient Networks project. The Ambient Networks project is part of the European Community's Sixth Framework Program for research and is as such funded by the European Commission. All information in this document is provided “as is” and no guarantee or warranty is given that the information is fit for any particular purpose. The user thereof uses the information at its sole risk and liability. For the avoidance of all doubts, the European Commission has no liability in respect of this document, which is merely representing the authors‘ view.

2 Background Main focus areas of wireless network security: Authentication & key exchange Per-packet encryption & integrity protection Assumptions Authorization “happens” at some point Policy lookup based on authenticated identity Not entirely accurate picture… This is work in progress Issues that should be taken into account in the future, not finished solutions

3 Business aspects Enforcing policies about money is somewhat different from policies about authenticated identities “Anyone who pays is allowed” “A, B, and C are allowed” In traditional “subscription” model with off-line accounting these are quite close But not in, e.g., credit card payment Or pre-paid with on-line “reservations” Much more than “authentication problem” New meanings for messages RADIUS Access-Accept = “Yes, give access” (intra-operator) “I agree to pay the costs for this user’s session” (inter-operator) Authentication After authentication, AP does not necessarily know any long-term identifier for the user

4 Multiple players Not just “the network” Multiple entities/players involved in authorization WLAN access point Access network/WISP AAA + maybe other entities Roaming broker/mediating network AAA Home network/ISP AAA + maybe other entities Enterprise buying the service for its employees

5 Protocol boundaries Multi-party system specified as several two-party protocols Often developed separately Difficult to get the boundaries right And difficult to change them when requirements change Current list i 802.1X-REV EAP framework EAP methods RADIUS base (RFC2865) RADIUS EAP support (RFC3579) RADIUS EAP key transport (RFC2548) E.g., authentication of access point (or access network) identifier to client in the system including the protocols listed above We don’t even have a good name for this system…!

6 Lots of protocols, but… System with N participants has potentially possible interactions Do we have communication channels for all those? Client – AP: , 11i, 1X Client – Home AAA: EAP framework + methods AP – AAA proxies – Home AAA: RADIUS ( ) N2N2

7 Missing protocol! Missing: communication channel between client and AAA infrastructure (other than home AAA)! Current experience suggests this is needed for information about the access network (not just single AP) Roaming relationships Services provided Handoff Current approaches Modify non-integrity-protected fields in EAP messages Proprietary EAP method run between client/access network before the “real” authentication “Browser hijack”

8 Problems with current approaches Not secure Who is the “authority” for the information? Usually not the access point… Very limited amount of information can be transferred “Browser hijack” breaks other network uses than browsing EAP-based methods work only in the beginning Proprietary solutions not widely adopted Performance (potentially)

9 Authorization aspects in handoffs Scope Is the new AP covered by the home network’s “promise to pay”? Does the new AP accept this promise? Currently scope not communicated explicitly But including the policy in Access-Accept means only some policies can be expressed What kind of policies are really needed? Are APs the right place to evaluate this policy anyway? Does the AP have the information needed to evaluate it?

10 Authorization and handoffs Context transfer between old and new AP is not enough Session termination initiated by the network Upstream AAA proxy needs to be notified “Chasing the fly around the room”  use handoffs to escape disconnect messages draft-liu-aaa-diameter-session-mobility-00 (expired) Can e.g. price be different in new AP?

11 What can be learned? This is not (just) a “key management problem” And handoffs are not (just) a “context transfer problem” Design is often incremental Dial-up PPP with PAP/CHAP RADIUS between NAS and AAA server Inter-domain RADIUS Per-packet encryption/integrity protection EAP for user authentication WLAN as “wired Ethernet replacement” Mutual authentication in EAP Public WLAN networks Network discovery/selection Three-party authentication in EAP? “WLAN as 4G”??

12 What can be learned? Business aspects Avoid hardcoding business models and policies into protocols Cannot be avoided totally, though Network-initiated messages in current AAA Difficult to route Problems with handoffs Credit card payment and i Reuse of existing user databases and credentials One thing EAP got right? Rise of the “mediating network”

13 What can be learned? Protocols Reusing existing components is sound engineering practice But so is throwing away components that don’t fit Be explicit about what is meant and expected of others E.g., NAS/AP does not tell what attributes it wants from the AAA server Get modular boundaries right Separating “security protocol” and protocol for “doing the real work” not always a good idea Create a protocol for doing the work securely instead Cf “network attachment” and 11i/1X “secure network attachment” … Not always clear what the “real work” is? IKEv1 was designed for “key management” “Real work” turned out to be VPN access

14 Multi-party systems New uses may require new parties in the system Do not design individual components in a vacuum Acknowledge that system has multiple parties, not just 2 Make them “first class citizens”: explicitly identify them Provide proper communication channels E.g., “go to this URL to do something about your authorization” instead of “browser hijack” Prior, during, and after network attachment Network discovery/selection information Notifications during network access Prepare for extensibility But in a way that fits to the overall architecture

15 Conclusions We don’t know how to do multi-party systems well And no silver bullets in this presentation either Challenges Incremental change Re-use of existing components vs. designing new ones Unexpected uses Component vs. system focus “Business security” vs. “information security” focus?