Transcript 802 21-IEEE-Security_Tutorial

IEEE 802.21 MEDIA INDEPENDENT HANDOVER
DCN: 21-08-0080-02-0sec-security-signaling-during-handoverstutorial
Title: Media-Independent Handover Security Tutorial
Date Submitted: March 18, 2008
Presented at IEEE 802.21 session #25 in Orlando
Authors or Source(s):
Yoshihiro Ohba (Toshiba), Marc Meylemans (Intel), Subir Das
(Telcordia Technologies)
Abstract: This document provides a tutorial on Media-Independent
Handover Security
21-08-0080-02-0sec
1
IEEE 802.21 presentation release statements
This document has been prepared to assist the IEEE 802.21 Working Group. It is
offered as a basis for discussion and is not binding on the contributing
individual(s) or organization(s). The material in this document is subject to
change in form and content after further study. The contributor(s) reserve(s)
the right to add, amend or withdraw material contained herein.
The contributor grants a free, irrevocable license to the IEEE to incorporate
material contained in this contribution, and any modifications thereof, in the
creation of an IEEE Standards publication; to copyright in the IEEE’s name
any IEEE Standards publication even though it may include portions of this
contribution; and at the IEEE’s sole discretion to permit others to reproduce in
whole or in part the resulting IEEE Standards publication. The contributor also
acknowledges and accepts that this contribution may be made public by IEEE
802.21.
The contributor is familiar with IEEE patent policy, as stated
outlined
in in
Section
Section
6 of
6.3the
of
the IEEE-SA
IEEE-SA
Standards
Standards
Board
Board
bylaws
Operations Manual
<http://standards.ieee.org/guides/opman/sect6.html#6.3> and
<http://standards.ieee.org/guides/bylaws/sect6-7.html#6>
and in
in
Understanding Patent Issues During IEEE Standards Development
http://standards.ieee.org/board/pat/guide.html>
http://standards.ieee.org/board/pat/faq.pdf>
21-08-0080-02-0sec
2
Agenda
• Overview of IEEE 802.21
• Network Access Security Model
• Intra-technology Handovers
• Overview of existing link-layer security signaling
optimizations
• Inter-technology Handovers
• Overview of potential approaches
• Proposed Directions
21-08-0080-02-0sec
3
Overview of 802.21
Please refer to the Tutorial presented in
July 2006
http://www.ieee802.org/21/Tutorials/802%2021-IEEE-Tutorial.ppt
21-08-0080-02-0sec
4
IEEE 802.21 Standard
Media Independent Handover Services
• Optimize Layer 3 and above Handovers
•
(e.g., 802.3 <> 802.11 <> 802.16 <> Cellular)
• Key Services
•
L2 Triggers and Measurement Reports
•
•
•
Information Service
•
•
•
802.11, 802.16 radios
Enables Network Initiated Handovers
Optimum Network Discovery and Selection
Lower Power operation for Multi-Radio devices
Handover Messages
•
•
Between Mobile Node (MN) <>Point of Service (PoS) (e.g., BS/AP)
Between PoS1 <> PoS2 (Resource Query, HO Indication)
• Further Information is available at www.ieee802.org/21
21-08-0080-02-0sec
5
IEEE 802.21: Overview
Applications
(VoIP/RTP)
L2 Triggers
& Measurements
State Change
Predictive
Handover ManagementNetwork Initiated
Handover
Policy
Mobility Management Protocols
IETF
Connection
Management
802.21 MIH Function
L2 Triggers
and Events
WLAN
Information
Handover
Service Commands
Handover
Messages
Handover
Messages
IEEE 802.21
Smart
Triggers
Network Information
Available Networks
Neighbor Maps
Network Services
Client Initiated
Network Initiated
Information
Service
Vertical Handovers
Cellular
WMAN
Protocol and Device Hardware
21-08-0080-02-0sec
6
General MIH Reference Model and
Service Access Points (SAPs)
MIH Services
(ES, CS, IS)
MIH Protocol
Transport
(Layer 2 or
Layer 3)
MIH_NET_SAP
MIH_NET_SAP
MIH Protocol
Layer 3 or
Higher Layer
Mobility Protocol
LLC_SAP
MIH_LINK_SAP
MIH
Services
(ES,
CS,
IS)
MIH Users
MIH_SAP
Media-Independent
Handover Function
(MIHF)
Remote
MIHF
Link Layer
(IEEE 802.3,
IEEE 802.11,
IEEE 802.16)
SAPs defined in IEEE 802.21 Specification
21-08-0080-02-0sec
7
Technical Challenges in Handovers
Challenge
Motivation
Efficient Network
Discovery and Selection
Inter-Network Neighbor Advertisements reduce
power consumption in scanning. The 802.11
module will only turn on if 802.11 coverage is
available
Low Latency Handovers
Requires inter-RAT interface. Speeds up handoff
procedure (passing security keys, resource
reservation).
Service Provider’s Control
in Target Network
Selection
Enables service providers to enforce handoff
policies and decisions. Requires inter-RAT
measurement reporting
Service Continuity
Eliminate L3 mobility signaling in inter-RAT
mobility by keeping L3 anchor in the previous RAT
access gateway. Requires inter-RAT interface
Target Preparation is the Key aspect of Optimized Handovers
21-08-0080-02-0sec
8
Key Interfaces for Handovers
3. Network-initiated Handovers
Require Measurement Reports
and H/O messages over Core
Network and air-interface
AG-RAT1
1. Inter-RAT Neighbor
Advertisements.
Common Core
Mobile Station
(MS)
2. Inter-Access Gateway
I/f Pass network context
from Source to Target for
Optimized Handovers
RAG
AG-RAT2
HLR
HSS
Information
Server
HA
AAA
AG: Access Gateway
RAT: Radio Access Technology
HA: Home Agent
21-08-0080-02-0sec
9
802.21 History & Timeline
1H
2004
802.21 WG
Created
2H
2004
1H
2005
14 Initial
Proposals
2H
2005
1H
2006
2H
2006
WG Letter
Ballot
Initiate Amendments to
802.11u, 802.16g.
IETF (MIPSHOP) on L3
Call For
Proposals
Down selection Initial
802.21 Draft Text
Year
2008
Year
2007
Sponsor
Ballot
20092010
802.21
Deployment*
802.21 Spec
Ratified*
*Projected Timelines
Two New Study Groups (July – 2007)
- Security in Handovers
- Multi-Radio Power Management
21-08-0080-02-0sec
10
Network Access Security Model
21-08-0080-02-0sec
11
Network Access Security Steps
Step 1: Network access authentication
Step 2: Secure association
Step 3: Access control and ciphering
Entities involved:
•
•
•
MN: Mobile Node
PoA: Point of Attachment (e.g., Access
Point)
AS: Authentication Server (e.g., AAA
server)
MN
PoA
AS
Step 1: Network Access Authentication
Step 2: Secure Association
Step 3: Access Control
and Ciphering
MN changes its PoA due to handover
Network access security is all about how to bind the three steps
together to provide appropriate security properties for network
access with the use of security associations (SAs)
21-08-0080-02-0sec
12
Security Associations (SAs)
SAmp: An SA between MN and PoA
SAma: An SA between MN and AS
SApa : An SA between PoA and AS
•
•
•
SApa is pre-established through AAA or other protocols
SAma will be established through a mutually authenticated key establishment
as an access authentication (in Step 1)
SAmp is dynamically established with creation of a Session Key
AS
SAma
MN
21-08-0080-02-0sec
SApa
SAmp
PoA
13
Step 1 - Network Access Authentication
MN*
PoA*
AS*
EAP-Request
EAP-Response
EAP-Request
:
EAP-Success
AAA{EAP-Response}
AAA{EAP-Request}
:
AAA{EAP-Success,MSK}
* Note: MN, PoA and
AS are EAP peer,
authenticator and
server, respectively,
and represent one
deployment model.
• MN and AS conduct EAP to establish SAmp
• EAP (Extensible Authentication Protocol) exports two keys:
•
•
MSK (Master Session Key) - distributed from AS to PoA protected by SApa
EMSK (Extended Master Session Key) – used for other purpose
• EAP is transported at link-layer as well as higher layers
•
•
Link-layer EAP transport in IEEE 802: 802.1X, PKMv2
Higher-layer EAP transport: PANA (Protocol for carrying Authentication for
Network Access), IKEv2 (Internet Key Exchange version 2), RADIUS/Diameter
21-08-0080-02-0sec
14
Step 2 – Secure Association
• A link-layer specific procedure to attach to a PoA in a secure
manner
Step 2-1: Provide and verify proof of each other’s possession
of the session key corresponding to SAmp
Step 2-2: Create access control filters and ciphering keys
• The ciphering keys are used in Access Control and
Ciphering (Step 3)
21-08-0080-02-0sec
15
Step 3 – Access Control and Ciphering
• Access control enforces link-layer data frames to be exchanged
between MN and PoA only after a successful run of Network
Access Authentication and Secure Association
• Link-layer data frames are cryptographically protected with the
use of ciphering keys depending on underlying link-layer
technologies
21-08-0080-02-0sec
16
Security Signaling Latency
• Approximately 90% of the latency originates from the EAP signaling
during network access authentication (full authentication)
• EAP authentication takes on average 100s of ms, while the layer 2 key
management (4-way handshake (HS) in 802.11 and 3-way handshake in
802.16) takes on average less than 10ms.
802.11
802.16
MN: Mobile Node
AP: Access Point
BS: Base Station
AAA: AAA server
21-08-0080-02-0sec
17
Handover Scenarios
• Two Common Cases
• Intra-technology Handovers
• Inter-technology Handovers
21-08-0080-02-0sec
18
Intra-Technology Handovers
21-08-0080-02-0sec
19
Solutions Available Today
• Several handover solutions available today are centered around
intra-technology handovers (AP to AP, BS to BS and typically
within the same AAA domain)
• IEEE 802.11 solutions:
• Pre-authentication (as defined in 802.11i)
• Fast BSS Transition (under Sponsor Ballot in TGr)
• IEEE 802.16 solution:
• Handover Process Optimization (as defined in 802.16e)
• IEEE 802.1 solution
• Roaming (reconnect) solution (under letter Ballot in 802.1af)
• Main goal of the above solutions is to decrease the time it takes
to do an EAP-based network access authentication
21-08-0080-02-0sec
20
802.11i - Pre-authentication
•
STA Associated to AP1, after full
802.11i authentication
•
Data traffic flows via AP1
•
STA selects AP2 as Target, and
initiates pre-Authentication for
AP2
•
EAP Authentication is sent via
AP1
•
AP2 receives MSK from EAP
Server
Conceptual Flow
AAA server
Internet
802.11 Access
Network
MSK
AP1
AP2
•
STA derives MSK for AP2
•
STA performs 802.11i 4-Way
Handshake with AP2, using
MSK(STA, AP2)
•
Data Traffic Flows via AP2
MSK
•
Transition complete
PTK
PTK
STA
21-08-0080-02-0sec
21
802.11r – Fast BSS Transition
•
•
•
•
•
•
•
•
•
•
•
•
STA Associated to AP1
Data traffic flows via AP1
STA Moves and Selects AP2 as
Target
802.11r Auth Request
Request PMK-R1AP2 from R0KH
Derive PMK-R1AP2 for AP2
Response w/ PMK-R1AP2 to AP2
802.11r Auth Response
AP2 & STA Derive PTK
802.11r Reassociation Request
and Response
Data traffic flows via AP2
Transition complete
Conceptual Flow
AAA server
Internet
802.11 Mobility
Domain
PMK-R0
PMK-R1 AP2
AP1
AP2
PMK-R1 AP2
PTK
PMK-R0
PMK-R1 AP2
PTK
STA
21-08-0080-02-0sec
22
802.16e – HO Process optimization
•
MS connected with BS1, data traffic
flows
•
MS sends HO request (HO
optimization bits set, preferred BSs)
to BS1
•
BS1 forwards HO request to BS2
•
BS2 sends HO response back to
BS1
•
BS1 sends HO response back to MS
•
MS sends HO indication with BS2 as
target
•
BS1 forwards MS info and
connection context to BS2 (handover
TEKs, associated counters,
negotiated capabilities, CID
update,…)
•
MS ranges and attaches with BS2
•
Data traffic flows via BS2
Conceptual Flow
AAA server
Core
network
Internet
802.16 Access
network
AK2
AK1
BS1
BS2
MS
21-08-0080-02-0sec
23
IEEE P802.1af and 802.1AE
• IEEE P802.1af – a new revision of 802.1X for port access
control, it provides
•
Network access authentication, secure association and access control for
LAN/MAN
•
Network discovery
•
Allows a session key that was established between a Host and a Network
Access Point to be cached and reused when reconnecting back to any Network
Access Points within the same administrative domain
• IEEE 802.1AE - MAC Security
•
Provides ciphering for LAN/MAN
21-08-0080-02-0sec
24
Inter-Technology Handovers
21-08-0080-02-0sec
25
Dual and Single Radio Handovers
• Dual radio handover: The MN has two radios, and both radios
are transmitting at the same time during handovers. Target
preparation is done via the target radio.
•
Allows a ‘make-before-break’ handover at L1/L2 and as
such service disruption can be avoided.
• Single radio handover: The MN has two radios, but only one
radio is transmitting at a time due to co-existence, interference,
battery issues. Target preparation is done using the source radio.
•
Limited to ‘break-before-make’ handover at L1/L2 and as
such service disruption cannot be avoided without additional
optimization
21-08-0080-02-0sec
26
Dual-radio Handover Flow
•
MN connected with Radio 1
to AN1, and an application
session is active
•
MN moves, Radio 2 On
•
MN decides to perform HO to
AN2
•
MN authenticates with AN2
using Radio 2
•
Subsequent HO procedures
follow
•Including IP mobility
signaling and resource
reservation and so on
•
Application session continuity
is maintained on AN2
•
Radio 1 off or idle
21-08-0080-02-0sec
Conceptual Flow
AAA server
Core
Network
Access Network
1
Access Network
2
27
Single-radio Handover Flow
•
•
•
•
•
•
•
•
MN connected with Radio 1
to AN1, and an application
session is active
MN moves and decides to
perform HO to AN2
MN authenticates with AN2
via AN1
Subsequent HO procedures
follow
•Including IP mobility
signaling and resource
reservation and so on
Radio 1 Off/Idle
Radio 2 active
MN attaches to AN2
Application session continuity
is maintained on AN2
21-08-0080-02-0sec
Conceptual Flow
AAA server
Core
Network
Access Network
1
Access Network
2
28
What is the problem?
• Security-related signaling can increase the latency significantly
in single-radio handover efforts and in many cases service
continuity can not be met
• Handover techniques that assume concurrent radio usage
cannot be used
• Even for dual-radio devices it might make sense to reduce the
security-related signaling, as it decreases the time that both
radios need to be active and thus can increase battery life
• In addition, handovers between networks within the same AAA
domains or different AAA domains pose different challenges
21-08-0080-02-0sec
29
Potential Approach for Intra-AAA-domain
Handover – Key Hierarchy-based Transition
(1/3)
• Establish a key hierarchy through full authentication upon entry into the
AAA domain
• The key hierarchy may span multiple link-layer technologies
• Network access authentication is based on exchanging proof of possession of
the root key between MN and the root key holder through the PoA
Root Key
Session Key Session Key
for PoA_2
for PoA_1
21-08-0080-02-0sec
…
Session Key
for PoA_N
30
Potential Approach for Intra-AAA-domain
Handover – Key Hierarchy-based Transition (2/3)
• ERP (EAP Extensions for EAP Re-authentication Protocol) is
defined in IETF for Key Hierarchy-based Transition
• The server for ERP can be in a visited domain
• ERP requires one AAA message roundtrip
AAA domain X
Re-authentication Server
(AAA server/proxy)
ERP signaling
21-08-0080-02-0sec
31
Potential Approach for Intra-AAA-domain
Handover – Key Hierarchy-based Transition
(3/3)
• In this approach, ERP is proactively performed (proactive reauthentication)
• No AAA roundtrip after switching to the target PoA
AAA domain X
Re-authentication Server
(AAA server/proxy)
Proactive re-authentication
Secure Association
21-08-0080-02-0sec
32
Potential Approach for Inter-AAA-Domain
Handover – Authentication-based Transition
• Since networks are in different AAA domains, in general full
authentication can not be avoided
•
There is no reason for the new domain to “trust” keys from the old domain, and no reason
for mobile device to “trust” the new domain with keys it used with its old domain
•
Roaming agreements (SLAs) may exist between the two networks, but home operator
might still require the user to authenticate with the home network (AAA) because of
security or policy reasons
• A pre-authentication solution is needed that works across
multiple AAA domains
EAP server
AAA domain X
AAA domain Y EAP (RFC 3748)
signaling
Secure Association
21-08-0080-02-0sec
33
Proposed Direction in 802.21
• Proactive authentication is the promising approach to reduce
authentication and key establishment signaling latency
•
•
Needed for secure service continuity across different link-layer
technologies, AAA domains
Use existing media-specific Secure Association mechanisms
• Proactive authentication can be based on proactive reauthentication, and pre-authentication
• Proactive authentication requires an EAP transport
• The solution that works independent of link-layer technologies
• Our main scope is IEEE 802 technologies, but solution could be
applied to handovers to other technologies
21-08-0080-02-0sec
34
Thank You!
21-08-0080-02-0sec
35