Transcript PPT Version

Extensions to the Internet Threat Model
[email protected]
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
IETF 68, Prague,
March 2007
2
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
Prague,
 Offline cryptographic attacks

IETF 68,
March 2007
3
Network Asset Classification

Critical vs. non-critical assets

Critical assets: parties to the communication


Non-critical assets: parties that facilitate the
communication


end-hosts, network servers, authentication
infrastructure
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
IETF 68, Prague,
March 2007
fashion, yet entities are able to communicate

4
Critical and Non-critical Assets
MA

AR
Ensure service is not disrupted by
non-critical entities

AR
MN

Service provided via
uncompromised entities

MN
Mitigate domino effects
Entities: AR, HMIP AR, MIP4 FA,
NETLMM MAG, FMIP nAR
Compromise of one entity MUST NOT impact
sessions traversing other entities!
IETF 68, Prague,
March 2007
5
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



Identity assertion support
Consider candidate entities that might provide these
functions


all types: fast, hierarchical, network-based, etc.
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!
IETF 68, Prague,
March 2007
6
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
IETF 68, Prague,
March 2007
7
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
IETF 68, Prague,
March 2007
8
Breaking 4758
IETF 68, Prague,
March 2007
9
There’s Another Solution!
IETF 68, Prague,
March 2007
10
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?




IETF 68, Prague,
March 2007
Decrease the payoff of an attack
Follow Housley Criteria
Tamper-resistance, IBM 4758 story not withstanding
OR, employ women with guns at each EP?
11
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
IETF 68, Prague,

March 2007
This still allows containing an attack to within the
12
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
IETF 68, Prague,
March 2007
13
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
IETF 68, Prague,
March 2007
14
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
IETF 68, Prague,
March 2007
15
Backup
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-ipmobility-threats-00
…
IETF 68, Prague,
March 2007
17