Delay Tolerant Networks - Some Thoughts about Security

1. Delay Tolerant Networks-Some Thoughts about Security Hannes Tschofenig This presentation has been produced 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 presentation 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 presentation, which is merely representing the authors view.

2. Acknowledgment • Some slides are based on input and discussions with Jari Arkko and Pasi Eronen.

3. End-to-end Connectivity Available M F Wireless network Internet Intermediary peers to isolate the wireless link Mobile network Im F M Wireless network Internet If End-to-end Store-and-Forward I2 I4 Wireless network M F Internet I1 Wireless network I3 Design Space Overview (1/2) End Host interacts with a proxy Wireless network If F M Internet

4. Design Space Overview (2/2) • Solution affecting parts: • What are the devices that need to be signaled? • How many of them? (end hosts only vs. many nodes along the path) • Where are they? What is the relationship between the end host and these boxes? • DTN Properties • Possibly no e2e connectivity • Long or variable delay • Asymmetric data rates • High error rates • See above-issues • Calls for efficient mechanisms (roundtrip, bandwidth)

5. Security “Goals” • Hop-by-Hop / End-to-middle • Prevent access by unauthorized applications • Prevent applications from asserting control over the DTN infrastructure • End-to-End • Typically very application dependent • Hard to accomplish and have different properties than security offered to the middle of the network • There are many other issues: • Network hiding, user identity confidentiality, privacy, DoS, etc.

6. Network Access Authentication and Authorizationa) Why existing network access auth/authz might not be appropriate for DTNsb) Can the result of network access authentication be helpful for the DTN architecture?c) Are the existing concepts useful for DTN?

7. Some Current Problems 1 • DTN: Hosts might be partitioned in a number of connected clouds (possibly 1) • Reasonable to consider the entire protocol stack rather than a single protocol (particular if performance is important) • Attachments involve a large number of messages • Over 50% of this is due to security • Request/Response style, even across the Internet • Multiple mandatory waiting periods • Iteration over available accesses

8. other node access network client home Beacon 802.11 Attachment 802.11 Authentication IPv6 Router Discovery 802.1X and EAP 802.11i 4-Way HS IPv6 DAD Nemo/MIPv6 Reg MIPv6 RO Reg Current Procedure(IPv6 + WLAN)

9. Some Current Problems 2 • Limited information transfer & control • Network selection • Handoff guidance and control • Capabilities of a network not available to end host • Limited business model support • No ad hoc, no credit card, • Real-time AAA interaction

10. Fixing some selected aspects… • Some EAP methods are quite inefficient • Proposed alternatives: • EAP-PSK (lightweight symmetric mechanism) • EAP-IKEv2 (flexibility & efficiency)

11. Today - Subscription-based Network Access • Network Access based on trust relationship between MN<->AAAH, AAAH <-> AAAL • De facto keying architecture based on RADIUS/Diameter in relationship with EAP; Authentication in real-time between MN<->AAAH; • Establishment of session keys is an important consideration for the architecture • NOT well suited for a certain DTN architectures

12. Authorization • Why do so many architectures require interaction with the “home network”/third party? • Authorization provided by the home network (based on a dynamic set of attributes) • Credits, Number of concurrent sessions, Location • Attributes sent to the enforcement point (tunnel attributes, session lifetime, keying material, etc.) • Real-time interaction required to deal with pre-paid cards, accounting, credit checks, re-authorization • Bootstrapping of keying material • When is AAA alike interaction needed for applications? • Authorization decision different to network access authentication • When cleaner protocol separation is desired.

13. Re-Thinking Authorization • What would we like to accomplish? • Fewer roundtrips and more efficiency (with existing architectures) • Revised network access architecture • Avoid real-time interaction with home network User NAS Network Access Server AAA Proxy AAA Server PPP IEEE 802.1X/.11i IKEv2 PANA DIAMETER DIAMETER (RADIUS) Primary & Secondary Home Servers

14. Avoid real-time interaction with home network

15. Credential based Authorization • Real-time interaction with the home network is not necessary if authorization decision can be computed locally. • Example: • Authorization based on non-frequently changing attributes (such as roles or traits) • Ability to regularly push revocation lists or access control information to the enforcement points

16. Example: Digital Coins • Interaction between the Vendor and the TTP is still necessary to finally receive money. • Smaller monetary amounts might justify batch transactions. Challenge: Double Spending (Tradeoff between taken risk and amount of required AAA interaction) • Efficiency gain by using hash chains • Pay-as-you-go scheme offers cost control and non-repudiation

17. Network Access Authentication and Relationship to other protocols • Network Access Authentication authenticates and authorizes user at the home network. • Protocol interaction is quite heavy-weight. • Session keys are sent to the visited network • A number of other protocols are used between the end host and the visited network (or related networks).

18. Applicability of Bootstrapping • How do you bind the initial authentication and authorization to a subsequent protocol interaction? or • If you use other protocols do you again want to re-run an EAP exchange back to the home network? or • Would you like to use the initial authorization for subsequent protocol interactions?

19. DTN router – A Middlebox?

20. “Middlebox” Traversal ? DTN Gateway can be a DTN router, SIP proxy, performance enhancing proxy, HIP rendezvous server, NSIS node, etc.. Which gateway should I use?

21. Again some things to think about… • Discover middleboxes along the path dynamically? • Destination address based • Information within the request indicate the direction (impact on forwarding) • Register with middlebox to accomplish global reachability? • Support mobility within one “region”? • DTN gateway acts as a mobility anchor point. • Possibly in a nested fashion? • Reuse existing [channel] security mechanisms (including DoS protection)? • DoS protection not possible with one-shot signaling messages • Keep state at middleboxes to speed-up subsequent protocol interactions • Following the soft-state principle • Use delegation to off-load tasks

22. StrawmanEvaluate security of a “SIP-based” DTN • Network Attachment • Security issues previously discussed • Discovery of SIP-based DTN gateway: • Do you talk to a true gateway or just to the adversary? On path or not? • Authentication and Authorization to SIP proxy • Traditional approach difficult (AAA infrastructure) • Trait-based authorization based on SAML could work • Routing of SIP messages • DNS and/or DHT based => security • End-to-end security guarantees • S/MIME ~ suffers from classical deployment problems • Identifier (SIP URI) aspect requires further thoughts • Routing, anonymity, authorization, … (=> see next slides)

23. Identity of a Network

24. The Identity of a Network • DTN (region, entity) “Placing a DTN node in a particular region is an administrative decision, and may be influenced by differences in protocol families, connection dynamics, or administrative policies.” [draft-irtf-dtnrg-arch] • Example: • {internet.icann.int, http://www.ietf.org} • Late binding approach / intentional naming • Region seems to be used for routing only. • Aggregation capability assumes that there a structure in the identifier • Related questions: • What do you actually authenticate/authorize? • Do you need to show that you belong to a certain network? • How do you join? • What happens if the prerequisites for adding a node to a ‘region’ change?

25. Network IdentityFurther Examples • NEWARCH: trust boundaries • IPNL: Global/local address partitions • NSIS NATFW NSLP: • Receiver behind a NAT wants to indicate that the signaling messages terminate at the outermost NAT (private to public address space). • Same feature for a Firewall: Really difficult to say what the boundaries are. • Ambient Networks project: • Idea: Explicit naming; cryptographic identifiers, if possible. • SSID: • Most administrators of WLANs do not change the default SSID (see for example [Pri04] for a study about WLAN usage in London where approximately 40% of the access points are running their default SSID.) • The SSID is non-unique network name that provides only minimal information relating to the network that the STA may connect to. • Adrangi-Network-Selection: • Identity selection hints to allow mediating network selection • A syntax by which mediating network information can be represented. [Pri04] Priest, J.: "The State of Wireless London”, available at http://www.spacestudios.org.uk/content/articles/461.pdf, (July 2004), March 2004.

26. Conclusion • Delay Tolerant Networking means (like sensor networking) different things to different people. • Different solution vary a lot depending on the chosen requirements • Working on a security solution requires a good understanding of architecture and the assumptions • Since many aspects seem to be highly application dependent it seems reasonable to investigate existing approach first. • Good thing: • Pick an arbitrary security mechanism • Apply it to the DTN in your lab • It will just work fine