IEEE 802.

21 MEDIA INDEPENDENT HANDOVER

DCN: 21-08-0080-02-0sec-security-signaling-during-handovers-
tutorial
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

Wednesday, July 29, 2009

 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
The contributor
contributor grants
grants aa free,
free, irrevocable
irrevocable license
license toto the
the IEEE
IEEE to to incorporate
incorporate
material
material contained
contained in in this
this contribution,
contribution, andand any
any modifications
modifications thereof,
thereof, in
in the
the
creation
creation of
of an
an IEEE
IEEE Standards
Standards publication;
publication; to
to copyright
copyright in in the
the IEEE’s
IEEE’s name
name
any
any IEEE
IEEE Standards
Standards publication
publication even
even though
though itit may
may include
include portions
portions of
of this
this
contribution;
contribution; and
and at
at the
the IEEE’s
IEEE’s sole
sole discretion
discretion to
to permit
permit others
others to
to reproduce
reproduce in in
whole or in part the resulting IEEE Standards publication. The contributor
whole or in part the resulting IEEE Standards publication. The contributor also also
acknowledges
acknowledges and and accepts
accepts that
that this
this contribution
contribution may
may be be made
made public
public by
by IEEE
IEEE
802.21.
802.21.
The
The contributor
contributor is
is familiar
familiar with
with IEEE
IEEE patent
patent policy,
policy, as
as stated
outlinedin in
Section
Section6 of
6.3the
of
IEEE-SA Standards Board bylaws <http://standards.ieee.org/guides/bylaws/
the IEEE-SA Standards Board Operations Manual <http://standards.ieee.org/
sect6-7.html#6> and in Understanding
guides/opman/sect6.html#6.3> Patent Issues During
and in Understanding IEEE Standards
Patent Issues During
Development
IEEE Standards http://standards.ieee.org/board/pat/faq.pdf> 
Development http://standards.ieee.org/board/pat/guide.html> 

21-08-0080-02-0sec 2

Wednesday, July 29, 2009

 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

Wednesday, July 29, 2009

 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

Wednesday, July 29, 2009

 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
• 802.11, 802.16 radios
• Enables Network Initiated Handovers
• Information Service
• 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

Wednesday, July 29, 2009

 IEEE 802.21: Overview

L2 Triggers & Measurements

State Change
Predictive
Network Initiated
Network Information
Available Networks
Neighbor Maps
Handover Commands Network Services
Client Initiated
Network Initiated
Vertical Handovers

21-08-0080-02-0sec 6

Wednesday, July 29, 2009

 IEEE 802.21: Overview

L2 Triggers & Measurements

State Change
Predictive
Network Initiated
Network Information
Available Networks
Neighbor Maps
Handover Commands Network Services
Client Initiated
Network Initiated
Vertical Handovers

21-08-0080-02-0sec 6

Wednesday, July 29, 2009

 IEEE 802.21: Overview
L2 Triggers & Measurements
State Change
Predictive
Network Initiated
Network Information
Available Networks
Neighbor Maps
Handover Commands Network Services
Client Initiated
Network Initiated
Vertical Handovers

21-08-0080-02-0sec 6

Wednesday, July 29, 2009

 IEEE 802.21: Overview
L2 Triggers & Measurements
Applications (VoIP/RTP) State Change
Predictive
Connection Handover Network Initiated
Network Information
Management Policy Available Networks
Neighbor Maps
Handover Management Handover Commands Network Services
Client Initiated
Network Initiated

IETF
Mobility Management Protocols Vertical Handovers

Smart 802.21Handover
MIH Function
Information

IEEE 802.21
Triggers Messages Service

L2 Triggers Handover Information

and Events Messages Service

WLAN Cellular WMAN

Protocol and Device Hardware

21-08-0080-02-0sec 6

Wednesday, July 29, 2009

 IEEE 802.21: Overview
L2 Triggers & Measurements
Applications (VoIP/RTP) State Change
Predictive
Connection Handover Network Initiated
Network Information
Management Policy Available Networks
Neighbor Maps
Handover Management Handover Commands Network Services
Client Initiated
Network Initiated

IETF
Mobility Management Protocols Vertical Handovers

Smart 802.21Handover
MIH Function
Information

IEEE 802.21
Triggers Messages Service

L2 Triggers Handover Information

and Events Messages Service

WLAN Cellular WMAN

Protocol and Device Hardware

21-08-0080-02-0sec 6

Wednesday, July 29, 2009

 General MIH Reference Model and
Service Access Points (SAPs)

Remote Media-Independent MIH Users

MIHF Handover Function

MIH_SAP
(MIHF) Layer 3 or
Higher Layer
Mobility Protocol

MIH
Services MIH Services LLC_SAP
(ES,
CS, MIH Protocol (ES, CS, IS)
IS)

MIH_LINK_SAP
MIH_NET_SAP

MIH_NET_SAP

MIH Protocol Link Layer

Transport (IEEE 802.3,
(Layer 2 or IEEE 802.11,
Layer 3) IEEE 802.16)

SAPs defined in IEEE 802.21 Specification

21-08-0080-02-0sec 7

Wednesday, July 29, 2009

 Technical Challenges in Handovers

Challenge Motivation

Efficient Network Inter-Network Neighbor Advertisements reduce

Discovery and Selection 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 Enables service providers to enforce handoff
in Target Network policies and decisions. Requires inter-RAT
Selection 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

21-08-0080-02-0sec 8

Wednesday, July 29, 2009

 Technical Challenges in Handovers

Challenge Motivation

Efficient Network Inter-Network Neighbor Advertisements reduce

Discovery and Selection 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 Enables service providers to enforce handoff
in Target Network policies and decisions. Requires inter-RAT
Selection 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

Wednesday, July 29, 2009

 Key Interfaces for Handovers
AG-RAT1

RS

RAG HLR
Common
HSS Core
Mobile Station Information HA
Server AAA

RS
(MS)

AG-RAT2 AG: Access Gateway

RAT: Radio Access Technology
HA: Home Agent

21-08-0080-02-0sec 9

Wednesday, July 29, 2009

 Key Interfaces for Handovers
AG-RAT1
1. Inter-RAT Neighbor
Advertisements.

RS

RAG HLR
Common
HSS Core
Mobile Station Information HA
Server AAA

RS
(MS)

AG-RAT2 AG: Access Gateway

RAT: Radio Access Technology
HA: Home Agent

21-08-0080-02-0sec 9

Wednesday, July 29, 2009

 Key Interfaces for Handovers
AG-RAT1
1. Inter-RAT Neighbor
Advertisements.

RS

2. Inter-Access Gateway RAG HLR

I/f Pass network context Common
HSS Core
Mobile Station
from Source to Target for Information HA
Optimized Handovers Server AAA

RS
(MS)

AG-RAT2 AG: Access Gateway

RAT: Radio Access Technology
HA: Home Agent

21-08-0080-02-0sec 9

Wednesday, July 29, 2009

 Key Interfaces for Handovers
AG-RAT1 3. Network-initiated Handovers
1. Inter-RAT Neighbor Require Measurement Reports
Advertisements. and H/O messages over Core
Network and air-interface

RS

2. Inter-Access Gateway RAG HLR

I/f Pass network context Common
HSS Core
Mobile Station
from Source to Target for Information HA
Optimized Handovers Server AAA

RS
(MS)

AG-RAT2 AG: Access Gateway

RAT: Radio Access Technology
HA: Home Agent

21-08-0080-02-0sec 9

Wednesday, July 29, 2009

 802.21 History & Timeline
1H 2H 1H 2H 1H 2H Year Year 2009-
2004 2004 2005 2005 2006 2006 2007 2008 2010

802.21 WG 14 Initial WG Letter Sponsor 802.21

Created Proposals Ballot Ballot Deployment*

Initiate Amendments to
802.11u, 802.16g. 802.21 Spec
IETF (MIPSHOP) on L3 Ratified*

Call For Down selection Initial

Proposals 802.21 Draft Text *Projected Timelines

Two New Study Groups (July – 2007)

- Security in Handovers
- Multi-Radio Power Management

21-08-0080-02-0sec 10

Wednesday, July 29, 2009

 Network Access Security Model

21-08-0080-02-0sec 11

Wednesday, July 29, 2009

 Network Access Security Steps

Step 1: Network access authentication

Step 2: Secure association
MN PoA AS
Step 3: Access control and ciphering
Step 1: Network Access Authentication
Entities involved:
• MN: Mobile Node
• PoA: Point of Attachment (e.g., Access Step 2: Secure Association
Point)
• AS: Authentication Server (e.g., AAA
server) 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

Wednesday, July 29, 2009

 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 SApa

MN SAmp PoA

21-08-0080-02-0sec 13

Wednesday, July 29, 2009

 Step 1 - Network Access Authentication
MN* PoA* AS*

EAP-Request * Note: MN, PoA and

AS are EAP peer,
EAP-Response AAA{EAP-Response} authenticator and
EAP-Request AAA{EAP-Request} server, respectively,

: :
AAA{EAP-Success,MSK}
and represent one
deployment model.
EAP-Success

• 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

Wednesday, July 29, 2009

 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

Wednesday, July 29, 2009

 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

Wednesday, July 29, 2009

 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

Wednesday, July 29, 2009

 Handover Scenarios

• Two Common Cases

• Intra-technology Handovers
• Inter-technology Handovers

21-08-0080-02-0sec 18

Wednesday, July 29, 2009

 Intra-Technology Handovers

21-08-0080-02-0sec 19

Wednesday, July 29, 2009

 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

Wednesday, July 29, 2009

 802.11i - Pre-authentication
Conceptual Flow
AAA server

Internet

802.11 Access
Network

AP1 AP2

STA

21-08-0080-02-0sec 21

Wednesday, July 29, 2009

 802.11i - Pre-authentication
Conceptual Flow
AAA server

Internet

802.11 Access
Network

AP1 AP2

STA

21-08-0080-02-0sec 21

Wednesday, July 29, 2009

 802.11i - Pre-authentication
Conceptual Flow
• STA Associated to AP1, after full
802.11i authentication AAA server

Internet

802.11 Access
Network

AP1 AP2

STA

21-08-0080-02-0sec 21

Wednesday, July 29, 2009

 802.11i - Pre-authentication
Conceptual Flow
• STA Associated to AP1, after full
802.11i authentication AAA server

• Data traffic flows via AP1 Internet

802.11 Access
Network

AP1 AP2

STA

21-08-0080-02-0sec 21

Wednesday, July 29, 2009

 802.11i - Pre-authentication
Conceptual Flow
• STA Associated to AP1, after full
802.11i authentication AAA server

• Data traffic flows via AP1 Internet

• STA selects AP2 as Target, and
initiates pre-Authentication for
AP2

802.11 Access
Network

MSK
AP1 AP2

STA

21-08-0080-02-0sec 21

Wednesday, July 29, 2009

 802.11i - Pre-authentication
Conceptual Flow
• STA Associated to AP1, after full
802.11i authentication AAA server

• Data traffic flows via AP1 Internet

• STA selects AP2 as Target, and
initiates pre-Authentication for
AP2
• EAP Authentication is sent via
AP1 802.11 Access
Network

MSK
AP1 AP2

MSK

STA

21-08-0080-02-0sec 21

Wednesday, July 29, 2009

 802.11i - Pre-authentication
Conceptual Flow
• STA Associated to AP1, after full
802.11i authentication AAA server

• Data traffic flows via AP1 Internet

• STA selects AP2 as Target, and
initiates pre-Authentication for
AP2
• EAP Authentication is sent via
AP1 802.11 Access
Network
• AP2 receives MSK from EAP
Server
MSK
AP1 AP2
PTK

ak y
sh Wa
e
nd 4-
Ha .11i
2
80
MSK

PTK

STA

21-08-0080-02-0sec 21

Wednesday, July 29, 2009

 802.11i - Pre-authentication
Conceptual Flow
• STA Associated to AP1, after full
802.11i authentication AAA server

• Data traffic flows via AP1 Internet

• STA selects AP2 as Target, and
initiates pre-Authentication for
AP2
• EAP Authentication is sent via
AP1 802.11 Access
Network
• AP2 receives MSK from EAP
Server
• STA derives MSK for AP2 AP1 AP2
MSK

PTK

MSK

PTK

STA

21-08-0080-02-0sec 21

Wednesday, July 29, 2009

 802.11i - Pre-authentication
Conceptual Flow
• STA Associated to AP1, after full
802.11i authentication AAA server

• Data traffic flows via AP1 Internet

• STA selects AP2 as Target, and
initiates pre-Authentication for
AP2
• EAP Authentication is sent via
AP1 802.11 Access
Network
• AP2 receives MSK from EAP
Server
• STA derives MSK for AP2 AP1 AP2
MSK

• STA performs 802.11i 4-Way PTK

Handshake with AP2, using

MSK(STA, AP2)

MSK

PTK

STA

21-08-0080-02-0sec 21

Wednesday, July 29, 2009

 802.11i - Pre-authentication
Conceptual Flow
• STA Associated to AP1, after full
802.11i authentication AAA server

• Data traffic flows via AP1 Internet

• STA selects AP2 as Target, and
initiates pre-Authentication for
AP2
• EAP Authentication is sent via
AP1 802.11 Access
Network
• AP2 receives MSK from EAP
Server
• STA derives MSK for AP2 AP1 AP2
MSK

• STA performs 802.11i 4-Way PTK

Handshake with AP2, using

MSK(STA, AP2)
• Data Traffic Flows via AP2
MSK

PTK

STA

21-08-0080-02-0sec 21

Wednesday, July 29, 2009

 802.11i - Pre-authentication
Conceptual Flow
• STA Associated to AP1, after full
802.11i authentication AAA server

• Data traffic flows via AP1 Internet

• STA selects AP2 as Target, and
initiates pre-Authentication for
AP2
• EAP Authentication is sent via
AP1 802.11 Access
Network
• AP2 receives MSK from EAP
Server
• STA derives MSK for AP2 AP1 AP2

• STA performs 802.11i 4-Way

Handshake with AP2, using
MSK(STA, AP2)
• Data Traffic Flows via AP2
• Transition complete

STA

21-08-0080-02-0sec 21

Wednesday, July 29, 2009

 802.11r – Fast BSS Transition
Conceptual Flow
AAA server

Internet

802.11 Mobility
Domain

PMK-R0

AP1 AP2

STA

21-08-0080-02-0sec 22

Wednesday, July 29, 2009

 802.11r – Fast BSS Transition
Conceptual Flow
AAA server

Internet

802.11 Mobility
Domain

PMK-R0

AP1 AP2

STA

21-08-0080-02-0sec 22

Wednesday, July 29, 2009

 802.11r – Fast BSS Transition
Conceptual Flow
• STA Associated to AP1
AAA server

Internet

802.11 Mobility
Domain

PMK-R0

AP1 AP2

STA

21-08-0080-02-0sec 22

Wednesday, July 29, 2009

 802.11r – Fast BSS Transition
Conceptual Flow
• STA Associated to AP1
AAA server
• Data traffic flows via AP1
Internet

802.11 Mobility
Domain

PMK-R0

AP1 AP2

STA

21-08-0080-02-0sec 22

Wednesday, July 29, 2009

 802.11r – Fast BSS Transition
Conceptual Flow
• STA Associated to AP1
AAA server
• Data traffic flows via AP1
• STA Moves and Selects AP2 as Internet
Target

802.11 Mobility
Domain

PMK-R0

AP1 AP2

STA

21-08-0080-02-0sec 22

Wednesday, July 29, 2009

 802.11r – Fast BSS Transition
Conceptual Flow
• STA Associated to AP1
AAA server
• Data traffic flows via AP1
• STA Moves and Selects AP2 as Internet
Target
• 802.11r Auth Request

802.11 Mobility
Domain

PMK-R0

PMK-R1 AP2 AP1 AP2

STA

21-08-0080-02-0sec 22

Wednesday, July 29, 2009

 802.11r – Fast BSS Transition
Conceptual Flow
• STA Associated to AP1
AAA server
• Data traffic flows via AP1
• STA Moves and Selects AP2 as Internet
Target
• 802.11r Auth Request
• Request PMK-R1AP2 from R0KH
802.11 Mobility
Domain

PMK-R0

PMK-R1 AP2 AP1 AP2 PMK-R1 AP2

STA

21-08-0080-02-0sec 22

Wednesday, July 29, 2009

 802.11r – Fast BSS Transition
Conceptual Flow
• STA Associated to AP1
AAA server
• Data traffic flows via AP1
• STA Moves and Selects AP2 as Internet
Target
• 802.11r Auth Request
• Request PMK-R1AP2 from R0KH
802.11 Mobility
• Derive PMK-R1AP2 for AP2 Domain

PMK-R0

PMK-R1 AP2 AP1 AP2 PMK-R1 AP2

STA

21-08-0080-02-0sec 22

Wednesday, July 29, 2009

 802.11r – Fast BSS Transition
Conceptual Flow
• STA Associated to AP1
AAA server
• Data traffic flows via AP1
• STA Moves and Selects AP2 as Internet
Target
• 802.11r Auth Request
• Request PMK-R1AP2 from R0KH
802.11 Mobility
• Derive PMK-R1AP2 for AP2 Domain
• Response w/ PMK-R1AP2 to AP2 PMK-R0

PMK-R1 AP2 AP1 AP2 PMK-R1 AP2

PTK

PMK-R0

PMK-R1 AP2

PTK
STA

21-08-0080-02-0sec 22

Wednesday, July 29, 2009

 802.11r – Fast BSS Transition
Conceptual Flow
• STA Associated to AP1
AAA server
• Data traffic flows via AP1
• STA Moves and Selects AP2 as Internet
Target
• 802.11r Auth Request
• Request PMK-R1AP2 from R0KH
802.11 Mobility
• Derive PMK-R1AP2 for AP2 Domain
• Response w/ PMK-R1AP2 to AP2 PMK-R0

• 802.11r Auth Response PMK-R1 AP2 AP1 AP2 PMK-R1 AP2

PTK

PMK-R0

PMK-R1 AP2

PTK
STA

21-08-0080-02-0sec 22

Wednesday, July 29, 2009

 802.11r – Fast BSS Transition
Conceptual Flow
• STA Associated to AP1
AAA server
• Data traffic flows via AP1
• STA Moves and Selects AP2 as Internet
Target
• 802.11r Auth Request
• Request PMK-R1AP2 from R0KH
802.11 Mobility
• Derive PMK-R1AP2 for AP2 Domain
• Response w/ PMK-R1AP2 to AP2 PMK-R0

• 802.11r Auth Response PMK-R1 AP2 AP1 AP2 PMK-R1 AP2

• AP2 & STA Derive PTK PTK

PMK-R0

PMK-R1 AP2

PTK
STA

21-08-0080-02-0sec 22

Wednesday, July 29, 2009

 802.11r – Fast BSS Transition
Conceptual Flow
• STA Associated to AP1
AAA server
• Data traffic flows via AP1
• STA Moves and Selects AP2 as Internet
Target
• 802.11r Auth Request
• Request PMK-R1AP2 from R0KH
802.11 Mobility
• Derive PMK-R1AP2 for AP2 Domain
• Response w/ PMK-R1AP2 to AP2 PMK-R0

• 802.11r Auth Response PMK-R1 AP2 AP1 AP2 PMK-R1 AP2

• AP2 & STA Derive PTK PTK

• 802.11r Reassociation Request

and Response

PMK-R0

PMK-R1 AP2

PTK
STA

21-08-0080-02-0sec 22

Wednesday, July 29, 2009

 802.11r – Fast BSS Transition
Conceptual Flow
• STA Associated to AP1
AAA server
• Data traffic flows via AP1
• STA Moves and Selects AP2 as Internet
Target
• 802.11r Auth Request
• Request PMK-R1AP2 from R0KH
802.11 Mobility
• Derive PMK-R1AP2 for AP2 Domain
• Response w/ PMK-R1AP2 to AP2 PMK-R0

• 802.11r Auth Response PMK-R1 AP2 AP1 AP2 PMK-R1 AP2

• AP2 & STA Derive PTK PTK

• 802.11r Reassociation Request

and Response
• Data traffic flows via AP2
PMK-R0

PMK-R1 AP2

PTK
STA

21-08-0080-02-0sec 22

Wednesday, July 29, 2009

 802.11r – Fast BSS Transition
Conceptual Flow
• STA Associated to AP1
AAA server
• Data traffic flows via AP1
• STA Moves and Selects AP2 as Internet
Target
• 802.11r Auth Request
• Request PMK-R1AP2 from R0KH
802.11 Mobility
• Derive PMK-R1AP2 for AP2 Domain
• Response w/ PMK-R1AP2 to AP2 PMK-R0

• 802.11r Auth Response PMK-R1 AP2 AP1 AP2 PMK-R1 AP2

• AP2 & STA Derive PTK PTK

• 802.11r Reassociation Request

and Response
• Data traffic flows via AP2
• Transition complete PMK-R0

PMK-R1 AP2

PTK
STA

21-08-0080-02-0sec 22

Wednesday, July 29, 2009

 802.16e – HO Process optimization
Conceptual Flow
AAA server

Core
network Internet

802.16 Access
network

AK1 AK2

BS1 BS2

MS

21-08-0080-02-0sec 23

Wednesday, July 29, 2009

 802.16e – HO Process optimization
Conceptual Flow
AAA server

Core
network Internet

802.16 Access
network

AK1 AK2

BS1 BS2

MS

21-08-0080-02-0sec 23

Wednesday, July 29, 2009

 802.16e – HO Process optimization
Conceptual Flow
• MS connected with BS1, data traffic
flows AAA server

Core
network Internet

802.16 Access
network

AK1 AK2

BS1 BS2

MS

21-08-0080-02-0sec 23

Wednesday, July 29, 2009

 802.16e – HO Process optimization
Conceptual Flow
• MS connected with BS1, data traffic
flows AAA server

• MS sends HO request (HO Core

network Internet
optimization bits set, preferred BSs)
to BS1
• BS1 forwards HO request to BS2

802.16 Access
network

AK1 AK2

BS1 BS2

MS

21-08-0080-02-0sec 23

Wednesday, July 29, 2009

 802.16e – HO Process optimization
Conceptual Flow
• MS connected with BS1, data traffic
flows AAA server

• MS sends HO request (HO Core

network Internet
optimization bits set, preferred BSs)
to BS1
• BS1 forwards HO request to BS2
• BS2 sends HO response back to
BS1 802.16 Access
network

AK1 AK2

BS1 BS2

MS

21-08-0080-02-0sec 23

Wednesday, July 29, 2009

 802.16e – HO Process optimization
Conceptual Flow
• MS connected with BS1, data traffic
flows AAA server

• MS sends HO request (HO Core

network Internet
optimization bits set, preferred BSs)
to BS1
• BS1 forwards HO request to BS2
• BS2 sends HO response back to
BS1 802.16 Access
network
• BS1 sends HO response back to MS

AK1 AK2

BS1 BS2

MS

21-08-0080-02-0sec 23

Wednesday, July 29, 2009

 802.16e – HO Process optimization
Conceptual Flow
• MS connected with BS1, data traffic
flows AAA server

• MS sends HO request (HO Core

network Internet
optimization bits set, preferred BSs)
to BS1
• BS1 forwards HO request to BS2
• BS2 sends HO response back to
BS1 802.16 Access
network
• BS1 sends HO response back to MS
• MS sends HO indication with BS2 as AK1 AK2
target
BS1 BS2

MS

21-08-0080-02-0sec 23

Wednesday, July 29, 2009

 802.16e – HO Process optimization
Conceptual Flow
• MS connected with BS1, data traffic
flows AAA server

• MS sends HO request (HO Core

network Internet
optimization bits set, preferred BSs)
to BS1
• BS1 forwards HO request to BS2
• BS2 sends HO response back to
BS1 802.16 Access
network
• BS1 sends HO response back to MS
• MS sends HO indication with BS2 as AK1 AK2
target
BS1 BS2
• BS1 forwards MS info and
connection context to BS2 (handover
TEKs, associated counters,
negotiated capabilities, CID update,
…)

MS

21-08-0080-02-0sec 23

Wednesday, July 29, 2009

 802.16e – HO Process optimization
Conceptual Flow
• MS connected with BS1, data traffic
flows AAA server

• MS sends HO request (HO Core

network Internet
optimization bits set, preferred BSs)
to BS1
• BS1 forwards HO request to BS2
• BS2 sends HO response back to
BS1 802.16 Access
network
• BS1 sends HO response back to MS
• MS sends HO indication with BS2 as AK1 AK2
target
BS1 BS2
• BS1 forwards MS info and
connection context to BS2 (handover
TEKs, associated counters,
negotiated capabilities, CID update,
…)
• MS ranges and attaches with BS2

MS

21-08-0080-02-0sec 23

Wednesday, July 29, 2009

 802.16e – HO Process optimization
Conceptual Flow
• MS connected with BS1, data traffic
flows AAA server

• MS sends HO request (HO Core

network Internet
optimization bits set, preferred BSs)
to BS1
• BS1 forwards HO request to BS2
• BS2 sends HO response back to
BS1 802.16 Access
network
• BS1 sends HO response back to MS
• MS sends HO indication with BS2 as AK1 AK2
target
BS1 BS2
• 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
MS

21-08-0080-02-0sec 23

Wednesday, July 29, 2009

 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

Wednesday, July 29, 2009

 Inter-Technology Handovers

21-08-0080-02-0sec 25

Wednesday, July 29, 2009

 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

Wednesday, July 29, 2009

 Dual-radio Handover Flow
Conceptual Flow

21-08-0080-02-0sec 27

Wednesday, July 29, 2009

 Dual-radio Handover Flow
Conceptual Flow

21-08-0080-02-0sec 27

Wednesday, July 29, 2009

 Dual-radio Handover Flow
• MN connected with Radio 1 Conceptual Flow
to AN1, and an application
session is active

21-08-0080-02-0sec 27

Wednesday, July 29, 2009

 Dual-radio Handover Flow
• MN connected with Radio 1 Conceptual Flow
to AN1, and an application
session is active
• MN moves, Radio 2 On

21-08-0080-02-0sec 27

Wednesday, July 29, 2009

 Dual-radio Handover Flow
• MN connected with Radio 1 Conceptual Flow
to AN1, and an application
session is active
• MN moves, Radio 2 On
• MN decides to perform HO to
AN2

21-08-0080-02-0sec 27

Wednesday, July 29, 2009

 Dual-radio Handover Flow
• MN connected with Radio 1 Conceptual Flow
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

21-08-0080-02-0sec 27

Wednesday, July 29, 2009

 Dual-radio Handover Flow
• MN connected with Radio 1 Conceptual Flow
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

21-08-0080-02-0sec 27

Wednesday, July 29, 2009

 Dual-radio Handover Flow
• MN connected with Radio 1 Conceptual Flow
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

21-08-0080-02-0sec 27

Wednesday, July 29, 2009

 Dual-radio Handover Flow
• MN connected with Radio 1 Conceptual Flow
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

21-08-0080-02-0sec 27

Wednesday, July 29, 2009

 Dual-radio Handover Flow
• MN connected with Radio 1 Conceptual Flow
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 27

Wednesday, July 29, 2009

 Single-radio Handover Flow
Conceptual Flow

21-08-0080-02-0sec 28

Wednesday, July 29, 2009

 Single-radio Handover Flow
Conceptual Flow

21-08-0080-02-0sec 28

Wednesday, July 29, 2009

 Single-radio Handover Flow
• MN connected with Radio 1 Conceptual Flow
to AN1, and an application
session is active

21-08-0080-02-0sec 28

Wednesday, July 29, 2009

 Single-radio Handover Flow
• MN connected with Radio 1 Conceptual Flow
to AN1, and an application
session is active
• MN moves and decides to
perform HO to AN2

21-08-0080-02-0sec 28

Wednesday, July 29, 2009

 Single-radio Handover Flow
• MN connected with Radio 1 Conceptual Flow
to AN1, and an application
session is active
• MN moves and decides to
perform HO to AN2
• MN authenticates with AN2
via AN1

21-08-0080-02-0sec 28

Wednesday, July 29, 2009

 Single-radio Handover Flow
• MN connected with Radio 1 Conceptual Flow
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

21-08-0080-02-0sec 28

Wednesday, July 29, 2009

 Single-radio Handover Flow
• MN connected with Radio 1 Conceptual Flow
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

21-08-0080-02-0sec 28

Wednesday, July 29, 2009

 Single-radio Handover Flow
• MN connected with Radio 1 Conceptual Flow
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

21-08-0080-02-0sec 28

Wednesday, July 29, 2009

 Single-radio Handover Flow
• MN connected with Radio 1 Conceptual Flow
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

21-08-0080-02-0sec 28

Wednesday, July 29, 2009

 Single-radio Handover Flow
• MN connected with Radio 1 Conceptual Flow
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

21-08-0080-02-0sec 28

Wednesday, July 29, 2009

 Single-radio Handover Flow
• MN connected with Radio 1 Conceptual Flow
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 28

Wednesday, July 29, 2009

 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

Wednesday, July 29, 2009

 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 … Session Key

for PoA_1 for PoA_2 for PoA_N

21-08-0080-02-0sec 30

Wednesday, July 29, 2009

 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 … Session Key

for PoA_1 for PoA_2 for PoA_N

21-08-0080-02-0sec 30

Wednesday, July 29, 2009

 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 … Session Key

for PoA_1 for PoA_2 for PoA_N

21-08-0080-02-0sec 30

Wednesday, July 29, 2009

 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 … Session Key

for PoA_1 for PoA_2 for PoA_N

21-08-0080-02-0sec 30

Wednesday, July 29, 2009

 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 … Session Key

for PoA_1 for PoA_2 for PoA_N

21-08-0080-02-0sec 30

Wednesday, July 29, 2009

 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 … Session Key

for PoA_1 for PoA_2 for PoA_N

21-08-0080-02-0sec 30

Wednesday, July 29, 2009

 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)

21-08-0080-02-0sec 31

Wednesday, July 29, 2009

 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

Wednesday, July 29, 2009

 Potential Approach for Intra-AAA-domain
Handover – Key Hierarchy-based Transition (3/3)

• In this approach, ERP is proactively performed (proactive re-

authentication)
• No AAA roundtrip after switching to the target PoA

AAA domain X
Re-authentication Server
(AAA server/proxy)

21-08-0080-02-0sec 32

Wednesday, July 29, 2009

 Potential Approach for Intra-AAA-domain
Handover – Key Hierarchy-based Transition (3/3)

• In this approach, ERP is proactively performed (proactive re-

authentication)
• No AAA roundtrip after switching to the target PoA

AAA domain X
Re-authentication Server
(AAA server/proxy)
Proactive re-authentication

21-08-0080-02-0sec 32

Wednesday, July 29, 2009

 Potential Approach for Intra-AAA-domain
Handover – Key Hierarchy-based Transition (3/3)

• In this approach, ERP is proactively performed (proactive re-

authentication)
• No AAA roundtrip after switching to the target PoA

AAA domain X
Re-authentication Server
(AAA server/proxy)

21-08-0080-02-0sec 32

Wednesday, July 29, 2009

 Potential Approach for Intra-AAA-domain
Handover – Key Hierarchy-based Transition (3/3)

• In this approach, ERP is proactively performed (proactive re-

authentication)
• No AAA roundtrip after switching to the target PoA

AAA domain X
Re-authentication Server
(AAA server/proxy)

Secure Association

21-08-0080-02-0sec 32

Wednesday, July 29, 2009

 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

21-08-0080-02-0sec 33

Wednesday, July 29, 2009

 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

21-08-0080-02-0sec 33

Wednesday, July 29, 2009

 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

21-08-0080-02-0sec 33

Wednesday, July 29, 2009

 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

Secure Association

21-08-0080-02-0sec 33

Wednesday, July 29, 2009

 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 re-

authentication, 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

Wednesday, July 29, 2009

 Thank You!

21-08-0080-02-0sec 35

Wednesday, July 29, 2009