1 dagstuhl dtn workshop 2005 delay tolerant networks - some thoughts about security hannes...

1Dagstuhl DTN Workshop 2005

Delay Tolerant Networks-

Some Thoughts about Security

Hannes TschofenigThis 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.


Acknowledgment

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


Design Space Overview (1/2)

Wirelessnetwork

End-to-end Connectivity Available

M FInternet

Wirelessnetwork

Internet FIf

Intermediary peers to isolate the wireless link

Mobilenetwork

M Im

Wirelessnetwork

Internet FIf

End Host interacts with a proxy

M

Wirelessnetwork

End-to-end Store-and-Forward

M FInternet

I4

I3

I2

I1

Wirelessnetwork


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 Properties1. Possibly no e2e connectivity2. Long or variable delay3. Asymmetric data rates4. High error rates

See above-issues


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.


Network Access Authentication and Authorization

a) 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?


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


clientaccess

network homeothernode

Beacon

802.11 Attachment

802.11 Authentication

802.1X and EAP

802.11i 4-Way HS

IPv6 Router Discovery

IPv6 DAD

Nemo/MIPv6 Reg

MIPv6 RO Reg

Current Procedure(IPv6 + WLAN)


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


Fixing some selected aspects…

• Some EAP methods are quite inefficient

• Proposed alternatives:– EAP-PSK (lightweight symmetric mechanism)– EAP-IKEv2 (flexibility & efficiency)


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


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.


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 NASNetworkAccessServer

AAAProxy

AAAServer

PPPIEEE

802.1X/.11i

IKEv2PANA

DIAMETER(RADIUS)

DIAMETER

Primary & SecondaryHome Servers


Avoid real-time interaction with home network


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


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

User as Customer

Network as Vendor

Trusted Third Party

Trust based on prior agreement or contract

Dynamically established trust relationship

Long-lived or pre-established agreement


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).


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?


DTN router – A Middlebox?


EndHost

“Region” A

DTNGateway

DTNGateway

DTNGateway

“Region” BDTN

Gateway

DTNGateway

“Region” C EndHost

“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..


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


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)


Identity of a Network


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?


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.


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

1 dagstuhl dtn workshop 2005 delay tolerant networks - some thoughts about security hannes...

Documents

dagstuhl dtn workshop

dtn properties

dtn infrastructure

dtn architecture

network hiding

wireless link mobile

client access network

end hosts