Transcript Secure and Efficient Network Access

Secure and Efficient
Network Access
DIMACS Workshop, November 3rd, 2004, Piscataway, NJ, USA
Jari Arkko
Ericsson Research NomadicLab
Pasi Eronen
Nokia Research Center
Pekka Nikander
Vesa Torvinen
Ericsson Research NomadicLab
This presentation has been produced partially 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 document 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 document,
which is merely representing the authors view
Arkko et al, DIMACS Workshop Nov ‘04
1
Presentation Outline
•
•
•
•
•
The Problem
Ongoing work
Some new ideas
An example protocol run
Conclusions
Arkko et al, DIMACS Workshop Nov ‘04
2
The Problem
Arkko et al, DIMACS Workshop Nov ‘04
3
Some Problems in Current Network
Access Approaches (1/3) - Efficiency
• Attachment involves a large number of messages
–
–
–
–
–
–
–
Scanning & 802.11 attachment
802.1X and EAP messaging
802.11i four-way handshake
DNA & IP router and neighbor discovery
Address autoconfiguration, DAD
Mobile IP home registration
Mobile IPv6 correspondent node registration
• Over 50% of this is due to security
• Request/Response style, even across the Internet
– Amount of data is growing with certificates, configuration, and discovery
• Multiple mandatory waiting periods
– Even a second, such as for DAD
• Iteration over available accesses
Arkko et al, DIMACS Workshop Nov ‘04
4
Some Problems in Current Network
Access Approaches (2/3) - Security
• “I’m one of the trusted network nodes” approach
– Sufficient for large cell size, well protected base stations
– Not very good for devices on the coffee shop wall
• Focus on authentication, not authorization
– Does everyone know/agree with the service parameters ?
• Denial-of-Service problems
– Use of cryptographic keys very late in the process
– Attacks that create/leave state to network side elements
– Insecure lower-layer “detach” messages
– 802.11 countermeasures functionality
• Privacy protection is non-existent or incomplete
Arkko et al, DIMACS Workshop Nov ‘04
5
Some Problems in Current Network
Access Approaches (3/3) - Functionality
• Security models do not fit all types of deployment
– Credit card payments
– Home deployments (e.g. leap of faith or physical connection instead of a
certificate exercise)
• Configuration, discovery, and movement support
–
–
–
–
What are the IP parameters that I can get from this access point?
Is my home operator available via this access point?
How much would accessing this network cost?
Could the network tell me when to move, and to what channel and
parameters to use?
Arkko et al, DIMACS Workshop Nov ‘04
6
Ongoing Work
Arkko et al, DIMACS Workshop Nov ‘04
7
Ongoing Work to Address the Problems...
• IP mobility
– Better implementations that employ parallism
allowed by the RFCs
– Faster route optimization schemes, such as
moving tasks out of the critical path
• Address autoconfiguration
– Turning DAD off
– Optimistic DAD
– DHCP and SEND security
Arkko et al, DIMACS Workshop Nov ‘04
8
Ongoing Work, Continued
• DNA, Router and Neighbor Discovery
– Faster algorithms for detecting whether or not
movement has occurred
– More frequent and precise router advertisements
– Elimination “first message” delays from RFC 2461
– SEND security
• EAP authentication
– Methods work (new credentials, deployment, …)
– Channel binding and parameter authentication
Arkko et al, DIMACS Workshop Nov ‘04
9
Ongoing Work, Continued
• Link layer
– Pre-authentication and proactive key distribution
– Better protection of payload packets (AES etc)
– Better information channels from the network to
the clients (e.g., 802.21)
– Discovery (WIEN SG)
– Faster scanning techniques, parameter tuning
– Bigger subnets (less IP layer work after
attachment)
– ...
Arkko et al, DIMACS Workshop Nov ‘04
10
Observations
• People care about this!
• A lot of results!
• Most work focused on a particular “slice” of
the problem
• No good understanding of what the impact of
individual improvement is for effiency
– E.g., “I can’t afford 1 RTT in Mobile IP”
• Not enough system-level understanding of
the security issues
Arkko et al, DIMACS Workshop Nov ‘04
11
Some New Ideas
Arkko et al, DIMACS Workshop Nov ‘04
12
Approach
• Focus on the problem as a whole!
–
–
–
–
–
–
There are multiple parties involved -- not just two
Who needs to communicate with who?
How are the parties identified?
What is the optimal order of messages?
What system security properties are needed?
Are there bulk information transfer needs? How
can they best be addressed?
– Can we learn something from solutions in other
contexts?
Arkko et al, DIMACS Workshop Nov ‘04
13
Caveat
• This may not be compatible with current
protocols
• Layer-purists might object to our views
• We do not have all the details, just pointers to
ideas
Arkko et al, DIMACS Workshop Nov ‘04
14
Potential Solution Ingredients (1/5)
Addressing:
• All nodes (not just the client) need an address
• Addresses are hashes of public keys
• Benefits:
– All parties -- such as the “access network” can be addressed
in communications
– Avoid address stealing and functionality to bind addresses to
credentials
– Nodes can generate their addresses and keys on their own,
without infrastructure
– Privacy can be achieved via ephemeral keys
• Identifier vs. routing semantics
Arkko et al, DIMACS Workshop Nov ‘04
15
Potential Solution Ingredients (2/5)
Message order:
• Find out what information the whole problem involves,
and how many messages need to carry it
• And re-think message order
• Example: If the client’s IP address was known earlier,
the authentication process with the home network could
handle mobility-related registrations as well
• Benefits:
– Number of messages can be reduced
– “Ping-pong” delays can be avoided
Arkko et al, DIMACS Workshop Nov ‘04
16
Potential Solution Ingredients (3/5)
Information transfer:
• Do not fetch everything from the original source
– Cache information about, say, roaming consortium in the AP
• Learn from TCP… no req-resp across the Internet
– Either run TCP-like protocols directly between the client and the, say,
home network
– Or have the access point do this over the Internet, and use a requestresponse over the final radio hop
• Information transfer capabilities should not be restricted
to the initial authentication exchange
• Benefits
– More and faster information transfer, at any time
Arkko et al, DIMACS Workshop Nov ‘04
17
Potential Solution Ingredients (4/5)
Miscallenous
• Delegation
–
–
–
–
Does the client have to be involved in tasks?
Can some tasks be delegated to the access point/router?
For instance, router based address assignment and DAD
Even a mobility related registration could be delegated
• Denial-of-Service protection
– No separation to “attachment” and “secure attachment”
– Stateless design on the network side
Arkko et al, DIMACS Workshop Nov ‘04
18
Potential Solution Ingredients (5/5)
Miscallenous, continued
• Privacy protection
– Build the protocols for non-static identifiers and addresses
– Protect communications from the start, not at the end
Arkko et al, DIMACS Workshop Nov ‘04
19
An Example Protocol Run
Arkko et al, DIMACS Workshop Nov ‘04
20
The Example
Flows:
–
–
–
–
Current message flow
Suggested basic message flow
Variant with better mobility support
Handoff
Assumptions:
–
–
–
–
Authentication needed; roaming case
IPv6
Mobility with RO & one peer
Client - home authentication in 2 RTT (identifier / challenge /
response / success)
Arkko et al, DIMACS Workshop Nov ‘04
21
Example: Current Flow
Arkko et al, DIMACS Workshop Nov ‘04
22
access
network
client
other
node
home
Beacon
802.11 Attachment
802.11 Authentication
802.1X and EAP
802.11i 4-Way HS
IPv6 Router Discovery
IPv6 DAD
MIPv6 Home Reg
MIPv6 RO Reg
Arkko et al, DIMACS Workshop Nov ‘04
23
Example: Improved Basic Flow
Arkko et al, DIMACS Workshop Nov ‘04
24
access
network
client
other
node
home
Beacon
Beacon includes:
- Access node identifier
- Access network identifier
- Possible other “advertised”
information, such as capabilities,
roaming partner identifiers, and so on
Arkko et al, DIMACS Workshop Nov ‘04
25
access
network
client
other
node
home
Beacon
Secure Attachment
The functions of the secure attachment
protocol:
- Authenticate the claimed identities
(opportunistically)
- Turn ciphering on, as in 802.11i 4-way
handshake
It also piggybacks the following:
- Deliver IPv6 router advertisements
- Authentication and authorization to the
home (partially)
Arkko et al, DIMACS Workshop Nov ‘04
26
- May perform address allocation on behalf
access
network
client
other
node
home
Beacon
Secure Attachment
I1: trigger
exchange
------------------------->
Arkko et al, DIMACS Workshop Nov ‘04
select pre-computed R1
R1: puzzle, D-H, key,
sig
<-----------------------check sig
remain stateless
solve puzzle
I2: solution, D-H, {key},
sig
------------------------->
compute D-H
27
access
network
client
other
node
home
Beacon
Secure Attachment
Home auth & authz
- The home authentication process
follows the
identity/challenge/response/success
model (for instance)
- A mobility protocol home
registration is carried in the same
messages -- executed after the final
response message is sent
Arkko et al, DIMACS Workshop Nov ‘04
28
access
network
client
other
node
home
Beacon
Secure Attachment
Home auth & authz
RO registration
1. Client delivers its public key, other
parameters, and a statement that delegates the
access network to allocate an address for it.
2. Access network has a statement from an authority
about the prefixes it “owns”. It constructs an
address and sends the address, the statement, and
the client’s information to the home network.
Arkko et al, DIMACS Workshop Nov ‘04
3. Home network sends the information along to the
correspondent node. Correspondent node believes the
validity of the care-of address since it trusts the
same authority. in a HIP-like mobility solution
there is no need to verify the home address;
client’s signed statement is sufficient.
29
Example: Variation with Better
Mobility Support
Arkko et al, DIMACS Workshop Nov ‘04
30
access
network
client
other
node
home
Beacon
Secure Attachment
Home auth & authz
RO registration
Care-of Address Test
Variation:
A common authority can be avoided by a care-of
address test.
Arkko et al, DIMACS Workshop Nov ‘04
31
Example: Handoffs
Arkko et al, DIMACS Workshop Nov ‘04
32
access
node 1
client
access
network
access
node 2
Beacon
Secure Attachment
- Access node 1 has a signed statement from
the access network that it is a part of the
network. This is given to the client.
- After authentication and authorization at
the home network, a set of explicit
authorization criteria are known. A signed
statement is given to the client, saying that
the client is allowed to move to another
access node within the same network, as long
as the criteria are fulfilled.
Arkko et al, DIMACS Workshop Nov ‘04
33
access
node 1
client
access
network
access
node 2
Beacon
Secure Attachment
Secure Attachment
- Access node 2 has a similar statement from
the access network as well.
- Client presents its statements and the
usual home authentication/authorization
process can be skipped. Client gets access.
Arkko et al, DIMACS Workshop Nov ‘04
- However, access node 2 needs to verify
authorization criteria. In many case this
implies contacting a central node in the
access network (e.g. concurrent usage limit).
34
Conclusions
Arkko et al, DIMACS Workshop Nov ‘04
35
Conclusions
• Need to look at the whole problem
– Measurements
– System-level security story
– Solutions
• Some early solution ideas presented
– Clearly more work is needed for the details,
security analysis & actual benefits
• Feedback appreciated!
Arkko et al, DIMACS Workshop Nov ‘04
36