Role of Authorization in
Wireless Network Security
Pasi Eronen
Jari Arkko
November 3, 2004
1
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.
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
2
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
3
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
4
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…!
5
Lots of protocols, but…
• System with N participants has potentially
interactions
( N2 )
possible
• 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
6
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”
7
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)
8
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?
9
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?
10
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”??
11
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”
12
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
13
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
14
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?
15