1. Themes From the Security Assessment Exercise Vern Paxson International Computer Science Institute and Lawrence Berkeley National Laboratory vern@icir.org June 27, 2007

2. Overview Each effort asked to assess its security vulnerabilities, assumptions & capabilities Responses from 21 groups (incl. adjuncts) Goal for this session: –Summarize, looking for themes –VP: some editorializing inevitable :-) Focus on what rather than who

3. Some Philosophical Points I liked For truly integrated security, security semantics must be understood by the network architecture, in the same way that semantics of endpoint, forwarding, routes, address, etc. are. For example, a step in a routing algorithm might read: –When an LSA is received from a currently trusted router about a link to a currently untrusted router... (from Rudra Dutta / SILO)

4. Philosophy, cont Carefully crafted custom network security features, based on cryptography or other software- intensive techniques, often get bypassed for a variety of reasons, especially due to ignorance, and configuration or performance frustrations (Ibid)

5. What Everyone Wants: Identity Prevalent assumption: verifiable, unspoofable identities However, scope varies … –Global PKI or secure name service –Enclave/Provider –Fundamentally scoped / chainable (MITs UIA) –Just a handle that persists consistently over time, unguessable ala capability … as does granularity: –End systems? Bill-payers?

6. What About Anonymity? Frequently not explicitly considered in assessment Some see as a service your (trusted) provider or a third-party can provide VP: I wonder about anonymity as an explicit type of identity (to align w/ policies) –Can picture shades of anonymity, e.g., crowd equivalence; persistent vs. transient

7. Identity & Attribution UCSD/UW effort Preserves privacy in absence of problem Assumes trusted end-system hardware Granularity is end-system / TPM –Not necc. tackling stepping-stone problem Effort also includes auditable exported content

8. Other Issues Regarding Identity Does it extend to identifying data? –Seems different: one-to-many, not one-to-one With virtualization, do identities ever need to cross between virtual domains? What about theft? Not discussed much. –Any general principles? VP: worry well have bootstrap problems unless basic design elements in place soon –E.g., well find we need routing to provide properties; for these, routing folks are relying on strong identities

9. Common Theme: Communication Setup Numerous efforts predicate communication on a setup phase that: –Provides point of consent, policy control/negotiation, billing –Allows generation of capabilities, rendezvous Granularity of associated identity affects amortization –Allows diffusion of service access E.g., anycast for initial service location –Provides point of sender work amplification VP: I wonder again about bootstrapping the design

10. Other Common Themes End systems will include (some) trusted hardware –VP: how far should we go in assuming this globally vs. itll often/sometimes be the case? How big a toehold? Crypto assumptions: –Can rely on strong, wire-speed crypto (non-pub-key) Availability of a solid trust system –Identifiers + authorization Secure routing assumed –VP: not clear what this is beyond connectivity. Network assures locators are proxies for identity?

11. Some Specific Themes Secure geo-location information –Sensornet building block Ideally, multi-resolution for degrees of anonymity But who controls this? Does user need to trust infrastructure? Does user ask for it, or does infrastructure impose it? –Could help some forms of defenses E.g., consistency checks on identity, resource consumption

12. Store-and-Forward Complexities If network accommodates significant forwarding delays, then –How do (semi-)isolated elements validate identity & authorization? –Loops might be optimal, rather than anathema –Thus, whats a replay attack vs. robust forwarding? Same problem can arise for multi-pathing

13. Network Inspection End system might ask network to inspect traffic on its behalf –DoS, attack filtering –Significant performance gains / resource conservation (e.g., caching, anti-spam) Or of course network may do it unasked Additional inspection for management, trouble-shooting –Who can do what with this information?

14. Exposing Security Costs Metrics for cost / benefit tradeoffs? –Cost = # messages (and presumably CPU) –What about: introduction of additional failure modes? Risk of identity exposure? Notions of explicitly selectable levels of security –E.g., global PKI vs. local vs. relying on cached credentials vs. self-signed identities for trust in presence of disconnection?

15. Leveraging Diversity Multiple viewpoints: allows consistency checks / cross validation –VP: crucial to accommodate these failing for benign reasons Diffuse locations for data, service –Of course, raises consistency & cost issues –As well as broader exposure of data, or at least visibility into who accesses it (Avoiding monocultures)

16. Issues Regarding Composition Interplay between network mechanisms & costs to security mechanisms –E.g., multipathing vs. amortizing session authentication information on a per-flow basis VP: will meta-networks wind up needing to support cross-talk? –If so, how are hyper-domains blended?

17. New Capabilities Robust routing will be much more adaptive in presence of attack –VP: not sure how much this fundamentally changes landscape vs. improves things somewhat Management providing greater, integrated views of activity & landscape –Both for direct security analysis & cross- validation

18. Things Not Discussed Much Billing & accountability: –Future network could have forms of billing that tie fine-grained user actions to $$ E.g., QoS, services accessed –This will necessarily drive notions of identity, accountability –DoS becomes $$ from end sources –Is there anything we can assume (or anti- assume) in this regard?

19. Things Not Discussed Much, cont DRM: –Inevitable this will spill over into the network? –Implications for content inspection, caching? Infrastructure threats beyond DoS: –Theft-of-service, theft-of-customer

20. Things Not Discussed Much, cont For new services, how to validate/audit that its fully/correctly provided? –…. in the presence of adversaries For both this and forms of network inspection, how to conduct these –At varying semantic levels –With non-global knowledge?

21. Things Not Discussed Much, cont Interdependence between security and management –What sort of security can management services themselves draw upon … –… given that they have to work when things (including security mechanisms) are broken?

22. Things Not Discussed Much, cont What about leveraging mutual aid and the fact that there are many more benign actual users than malicious ones? –E.g., collaborative filtering, aggregated/shared analysis –E.g., mechanisms for our friends / social networks to help us in times of overload or uncertainty –In the real world, selective trust is what makes society work

23. Things That Gave Me Pause Some assumptions that security issues could be addressed external to an effort –True: for pinpoint crypto ~ securing a session –False: for system properties / vulnerabilities –How do we best address this division? Distributed algorithms for which –Adversarial inputs not under consideration These differ from failures / misconfigurations –Or assumed readily thwarted (e.g., crypto)

24. Things We Should Work Out Soon Identity building blocks Assumptions about trusted hardware Maybe: role of billing / accountability Capture: –Spectrum of properties being assumed –Spectrum of properties being provided –And for these, what buy-in costs / assumptions do they entail?