1 / 15

Role of Authorization in Wireless Network Security

Role of Authorization in Wireless Network Security. Pasi Eronen Jari Arkko November 3, 2004.

ericholder
Download Presentation

Role of Authorization in Wireless Network Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Role of Authorization inWireless Network Security Pasi EronenJari ArkkoNovember 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 • 802.11 • 802.11i • 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. ( ) N2 Lots of protocols, but… • System with N participants has potentially possible interactions • Do we have communication channels for all those? • Client – AP: 802.11, 11i, 1X • Client – Home AAA: EAP framework + methods • AP – AAA proxies – Home AAA: RADIUS

  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 meansonly 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 802.11i • 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. 802.11 “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?

More Related