Extensions%20to%20the%20Internet%20Threat%20Model

1
Extensions to the Internet Threat Model

• ldondeti_at_qualcomm.com

2
Why Discuss this Topic?

• RFC 3552 describes the Internet Threat Model
• I am 0/2 with the co-author of that document this
  week
• I am going for the strike-out
• There is some work applying 3552 to IP mobility
• Developing best practices in mapping security
  functions to network entities
• Using an extended model in reviewing others docs
• Not in designing protocols for myself, mind you ?
• Need a sanity check on some of my own takeoffs
  there
• We might develop some more guidelines

3
RFC 3552 The Internet Threat Model

• Principles
• the attacker has nearly complete control of the
  communications channel
• Protecting against end-system compromise is
  difficult
• These are good, but we may need more!
• Classification of attacks
• Active vs. Passive attacks
• On-path vs. Off-path attacks
• Offline cryptographic attacks

4
Network Asset Classification

• Critical vs. non-critical assets
• Critical assets parties to the communication
• end-hosts, network servers, authentication
  infrastructure
• Non-critical assets parties that facilitate the
  communication
• access routers, access enforcement points
• As long as the critical assets are not
  compromised, things work
• We can say something stronger
• Non-critical assets may fail in a Byzantine
  fashion, yet entities are able to communicate

5
Critical and Non-critical Assets
MA

• Ensure service is not disrupted by non-critical
  entities
• Mitigate domino effects
• Service provided via uncompromised entities
• Entities AR, HMIP AR, MIP4 FA, NETLMM MAG, FMIP
  nAR

AR
AR
MN
MN
Compromise of one entity MUST NOT impact sessions
traversing other entities!
6
Mapping Security Functions to Network Entities

• Consider security functions such as
• Access control enforcement
• Key distribution for access control
• Key distribution for services, e.g., mobility
• all types fast, hierarchical, network-based,
  etc.
• Identity assertion support
• Consider candidate entities that might provide
  these functions
• Wireless Termination Points, Access Controllers,
  Access Gateways, Servers in the core network
• How might we do the mapping?
• It is desirable to not make non-critical entities
  critical!

7
Security at the Edge of the Network

• Edge devices in the access network are vulnerable
  to physical compromise
• WLAN and WWAN devices may be hanging off a wall
• It is plausible that people may tap into the
  network and enjoy free service or illegally
  resell!
• However we do want them to provide security
  services
• What kind of security are we talking about?
• Access control enforcement
• Key distribution
• Identity assertion support

8
Compromise of Edge Devices

• A real-world example
• ATM machines are edge devices of financial
  institutions
• Some banking systems use secure coprocessors to
  mitigate physical threat
• What does it take to extract keys from the IBM
  4758 (Costs about 5000)?
• about 20 minutes uninterrupted access to the
  device
• a standard off-the-shelf 995 FPGA evaluation
  board
• about two days of "cracking" time

9
Breaking 4758
10
Theres Another Solution!
11
Access Control Enforcement at the Edge

• Access control enforcement belongs at the edge
• There is a tussle on this issue
• Why not put the enforcement point (EP) deeper in
  the network?
• That may mean more spurious traffic in the
  backhaul
• There are also other reasons to put EP at the
  edge
• What happens if an EP is compromised?
• It may be plausible to steal service!
• How to mitigate the threat?
• Decrease the payoff of an attack
• Follow Housley Criteria
• Tamper-resistance, IBM 4758 story not
  withstanding
• OR, employ women with guns at each EP?

12
Edge Device as a Key Distributor

• KD functionality may increase the value of a
  device
• e.g., KD compromise reveals keys that may be used
  by many EPs
• May motivate the attacker to commit (more)
  resources
• The cost of securing the device increases
• And, there are limitations to tamper-resistance!
• There may be cases where this is ok
• Link layer security establishment as in 802.11
  DLP security comes to mind
• This still allows containing an attack to within
  the APs realm

13
Other Considerations in Selecting a KD

• Some designs proposed the use of an AR as the KD
  for keying mobility service
• AR is a non-critical asset it is better to keep
  it that way
• AR may be owned by a different entity than the
  entity providing mobility service
• If an AR misbehaves, the mobile may move to
  another AR and get service
• If the AR is a KD, this may not be plausible
• Does that rule out AR from providing security
  services?
• Well, no!
• What if the AR is the entity that needs to
  terminate an SA?
• Things get a bit more complex when AR is a
  non-critical resource even in this case

14
The Rest Belong in the Core

• The rest of the security functions belong in
  entities deeper in the network
• Credential stores
• Policy stores
• Entities that help verify identity assertions
• Many of these qualify as critical assets
• They are located in data centers with limited
  access

15
Summary

• We may need to extend the Internet threat model!
• We definitely need to provide more guidance to
  security protocol designers
• Asset classification guidance might help
• Guidelines on mapping security functions to
  network entities might prove useful

16
Backup
17
Other References

• AAA security guidelines in draft-housley-aaa-key-m
  gmt
• Generic threats to routing protocols, RFC 4593
• Threat analysis of mobility protocols,
  draft-vidya-ip-mobility-threats-00