Transcript Delay Tolerant Networks - Some Thoughts about Security

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.
Dagstuhl DTN Workshop 2005
1
Acknowledgment
• Some slides are based on input and
discussions with Jari Arkko and Pasi
Eronen.
Dagstuhl DTN Workshop 2005
2
Design Space Overview (1/2)
End-to-end Connectivity Available
M
Wireless
network
End-to-end Store-and-Forward
M
Wireless
network
F
Internet
I2
I4
Internet
I1
Wireless
network
F
I3
End Host interacts with a proxy
Wireless
network
M
If
Internet
F
Internet
F
Intermediary peers to isolate the wireless link
M
Dagstuhl DTN Workshop 2005
Mobile
network
Im
Wireless
network
If
3
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.
2.
3.
4.
Dagstuhl DTN Workshop 2005
Possibly no e2e connectivity
Long or variable delay
Asymmetric data rates
High error rates
See above-issues
Calls for
efficient
mechanisms
(roundtrip,
bandwidth)
4
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.
Dagstuhl DTN Workshop 2005
5
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?
Dagstuhl DTN Workshop 2005
6
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
Dagstuhl DTN Workshop 2005
7
Current Procedure
(IPv6 + WLAN)
client
access
network
other
node
home
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
Dagstuhl DTN Workshop 2005
8
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
Dagstuhl DTN Workshop 2005
9
Fixing some selected aspects…
• Some EAP methods are quite inefficient
• Proposed alternatives:
– EAP-PSK (lightweight symmetric mechanism)
– EAP-IKEv2 (flexibility & efficiency)
Dagstuhl DTN Workshop 2005
10
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
Dagstuhl DTN Workshop 2005
11
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.
Dagstuhl DTN Workshop 2005
12
Re-Thinking Authorization
• What would we like to accomplish?
User
NAS
AAA
AAA
Network
Access
Server
Proxy
Server
PPP
IEEE 802.1X/.11i
IKEv2
PANA
DIAMETER
DIAMETER
(RADIUS)
Primary & Secondary
Home Servers
– Fewer roundtrips and more efficiency
(with existing architectures)
– Revised network access architecture
– Avoid real-time interaction with home network
Dagstuhl DTN Workshop 2005
13
Avoid real-time interaction with home
network
Dagstuhl DTN Workshop 2005
14
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
Dagstuhl DTN Workshop 2005
15
Example: Digital Coins
•
•
Interaction between the Vendor and
the TTP is still necessary to finally
receive money.
Smaller monetary amounts might
justify batch transactions.
Trusted Third
Party
Long-lived or preestablished agreement
Trust based on prior
agreement or contract
Network as
Vendor
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
Dagstuhl DTN Workshop 2005
Dynamically established
trust relationship
User as
Customer
16
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).
Dagstuhl DTN Workshop 2005
17
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 rerun an EAP exchange back to the home network?
or
• Would you like to use the initial authorization for
subsequent protocol interactions?
Dagstuhl DTN Workshop 2005
18
DTN router –
A Middlebox?
Dagstuhl DTN Workshop 2005
19
“Middlebox” Traversal
DTN
Gateway
DTN
Gateway
“Region” A
DTN
Gateway
?
Which gateway
should I use?
End
Host
Dagstuhl DTN Workshop 2005
“Region” B
DTN
Gateway
DTN Gateway can
be a DTN router,
SIP proxy,
performance
enhancing proxy,
HIP rendezvous
server, NSIS node,
etc..
DTN
Gateway
“Region” C
End
Host
20
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
Dagstuhl DTN Workshop 2005
21
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)
Dagstuhl DTN Workshop 2005
22
Identity of a Network
Dagstuhl DTN Workshop 2005
23
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?
Dagstuhl DTN Workshop 2005
24
Network Identity
Further Examples
•
NEWARCH:
trust boundaries
•
IPNL:
Global/local address partitions
•
NSIS NATFW NSLP:
–
–
•
Ambient Networks project:
–
•
–
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:
–
–
[Pri04]
Idea: Explicit naming; cryptographic identifiers, if possible.
SSID:
–
•
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.
Identity selection hints to allow mediating network selection
A syntax by which mediating network information can be represented.
Priest, J.: "The State of Wireless London”, available at http://www.spacestudios.org.uk/content/articles/461.pdf, (July 2004), March 2004.
Dagstuhl DTN Workshop 2005
25
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
Dagstuhl DTN Workshop 2005
26