1. Extensions to the Internet Threat Model ldondeti@qualcomm.com

2. IETF 68, Prague, March 20072 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. IETF 68, Prague, March 20073 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. IETF 68, Prague, March 20074 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. IETF 68, Prague, March 20075 Critical and Non-critical Assets MN MA AR MN 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 Compromise of one entity MUST NOT impact sessions traversing other entities!

6. IETF 68, Prague, March 20076 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. IETF 68, Prague, March 20077 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. IETF 68, Prague, March 20078 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. IETF 68, Prague, March 20079 Breaking 4758

10. IETF 68, Prague, March 200710 There’s Another Solution!

11. IETF 68, Prague, March 200711 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. IETF 68, Prague, March 200712 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 AP’s realm

13. IETF 68, Prague, March 200713 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. IETF 68, Prague, March 200714 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. IETF 68, Prague, March 200715 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. IETF 68, Prague, March 200717 Other References AAA security guidelines in draft-housley-aaa-key-mgmt Generic threats to routing protocols, RFC 4593 Threat analysis of mobility protocols, draft-vidya-ip- mobility-threats-00 …