Role of Authorization in Wireless Network Security

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 users
  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 dont 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 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 networks
  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 dont 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 dont 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?