1 Dagstuhl DTN Workshop 2005 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 Dagstuhl DTN Workshop 2005 Acknowledgment Some slides are based on input and discussions with Jari Arkko and Pasi Eronen.

3 Dagstuhl DTN Workshop 2005 Design Space Overview (1/2) Wireless network End-to-end Connectivity Available MF Internet Wireless network Internet F IfIf Intermediary peers to isolate the wireless link Mobile network M ImIm Wireless network Internet F IfIf End Host interacts with a proxy M Wireless network End-to-end Store-and-Forward MF Internet I4I4 I3I3 I2I2 I1I1 Wireless network

4 Dagstuhl DTN Workshop 2005 Calls for efficient mechanisms (roundtrip, bandwidth) 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 1.Possibly no e2e connectivity 2.Long or variable delay 3.Asymmetric data rates 4.High error rates See above-issues

5 Dagstuhl DTN Workshop 2005 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 Dagstuhl DTN Workshop 2005 Network Access Authentication and Authorization a) Why existing network access auth/authz might not be appropriate for DTNs b) Can the result of network access authentication be helpful for the DTN architecture? c) Are the existing concepts useful for DTN?

7 Dagstuhl DTN Workshop 2005 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 Dagstuhl DTN Workshop 2005 client access network home other node Beacon Attachment Authentication 802.1X and EAP i 4-Way HS IPv6 Router Discovery IPv6 DAD Nemo/MIPv6 Reg MIPv6 RO Reg Current Procedure (IPv6 + WLAN)

9 Dagstuhl DTN Workshop 2005 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 Dagstuhl DTN Workshop 2005 Fixing some selected aspects… Some EAP methods are quite inefficient Proposed alternatives: –EAP-PSK (lightweight symmetric mechanism) –EAP-IKEv2 (flexibility & efficiency)

11 Dagstuhl DTN Workshop 2005 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 Dagstuhl DTN Workshop 2005 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 Dagstuhl DTN Workshop 2005 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 (RADIUS) DIAMETER Primary & Secondary Home Servers

14 Dagstuhl DTN Workshop 2005 Avoid real-time interaction with home network

15 Dagstuhl DTN Workshop 2005 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 Dagstuhl DTN Workshop 2005 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 Dagstuhl DTN Workshop 2005 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 Dagstuhl DTN Workshop 2005 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 Dagstuhl DTN Workshop 2005 DTN router – A Middlebox?

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

21 Dagstuhl DTN Workshop 2005 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 Dagstuhl DTN Workshop 2005 Strawman Evaluate 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 Dagstuhl DTN Workshop 2005 Identity of a Network

24 Dagstuhl DTN Workshop 2005 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, –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 Dagstuhl DTN Workshop 2005 Network Identity Further 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 (July 2004), March 2004.

26 Dagstuhl DTN Workshop 2005 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