IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-0297-00-0000 Title: Possible MIH security approaches and issues Date Submitted: September 12, 2007 Presented at IEEE 802.21 session.

Download Report

Transcript IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-0297-00-0000 Title: Possible MIH security approaches and issues Date Submitted: September 12, 2007 Presented at IEEE 802.21 session.

IEEE 802.21 MEDIA INDEPENDENT HANDOVER
DCN: 21-07-0297-00-0000
Title: Possible MIH security approaches and issues
Date Submitted: September 12, 2007
Presented at IEEE 802.21 session #22 in Hawaii
Authors or Source(s): Lily Chen (NIST), Subir Das (Telcordia),
Marc Meylemans (Intel), Sood Kapil (Intel), Srinivas
Screemanthula (Nokia), Michael Williams (Nokia), Yoshihiro
Ohba (Toshiba)
Abstract: This document provides an outline for 802.21 security
study group to discuss possible approaches.
21-07-0297-00-0000
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-07-0297-00-0000
2
Abstract
• Summarize the discussions to date related to 802.21 SSG.
• Reach common understanding about the possible approaches.
• Agree on terminologies used to describe each scenario.
• Analysis of each of the possible approaches.
• Identify 802.21 SSG tasks.
21-07-0297-00-0000
3
Two Security Problems*
• Problem 1: Security Signaling Optimization during Handover
• Problem 2: MIH level security mechanism
* We use the terms defined in 21-07-0122-04-0000-securityproposal.ppt
21-07-0297-00-0000
4
Problem 1
• When performming a handover,
• authenticate to attach to a new
point of attachment (PoA); and
• establish a new protected link
(confidentiality and integrity
protection) with the new point
of attachment.
• At the same time, all the
security solutions must
Current link
minimize delay.
Handover to a new connection:
21-07-0297-00-0000
1.
Authentication
2.
New protected link
5
Handover Scenarios
• Inter-domain without roaming agreement
•Authentication based handover*.
•Use
different credentials for authentication.
• Intra-domain or inter-domain** with roaming agreement
•Key hierarchy based handover*.
*We use the terms in 21-07-0124-00-0000-security-issues-intransition.ppt
**In the following, we treat inter-domain with roaming
agreement as intra-domain scenario.
Note that for hierarchy based handover, it may use a key in the
hierarchy to conduct a “local” authentication.
21-07-0297-00-0000
6
Inter-domain Scenarios
• Inter-domain scenario without roaming agreement in place, implies that
access authentication must be executed for each domain separately. (Here
“access authentication” means authentication with the long term credentials
established with the domain, for example, by EAP-TLS.)
• It may use pre-authentication to shorten the delay for handover. However,
for pre-authentication, we may also need some agreement.
• Two situations are under consideration.
• Over-the-air pre-authentication – The peer/mobile node direct request
access with the target point of attachment.
•
•
It must allow concurrent connections to different type of networks.
Over-the-DS pre-authentication – The peer/mobile node send access
request through the serving point of attachment.
•
The serving point of attachment must be able to direct the request to the correct
network entity which may belong to a different network (in a different domain).
• Question: Any work to be done in 802.21?
21-07-0297-00-0000
7
Intra-domain Scenarios
• Intra-domain handovers require a Key Hierarchy based solution
• Handovers between different media types
• HOKEY key hiearchy (EMSK derived root key)
• Re-authentication to trigger rMSK delivery.
*
Possible issue: For certain media, EAP may not be the access authentication
protocol.
• Handovers between the same media types
• Media-specific handover security solutions, e.g. 802.11r,
3GPP.
• It may use the key hiearchy established in a full access
authentication (use MSK as a root key).
•
•
Implicit authentication; and
Link layer key establishment (media specific).
21-07-0297-00-0000
8
Example: Key Hierarchy for 802.11r Fast Transition
Authenticator
Peer
AS
MSK
EAP
MSK
MSK
Peer new
location
21-07-0297-00-0000
Peer-new
location
9
HOKEY Hierarchy - Re-Authentication
Peer
Authenticator
AS
MSK
EAP
MSK
EMSK
rRK-1
Re-Authentication
rMSK-1
rMSK-1
rMSK-1
21-07-0297-00-0000
10
Possible Approaches
• Use HOKEY key hierarchy to generate root keys for handovers
between different media types
• HOKEY is media-independent.
• Use Post-EAP key hierarchy for handovers between the same
media types using rMSK as MSK.
• Minimize changes to existing handover technologies in
different technologies, e.g. 802.11r.
• Question: Any work to be done in 802.21 SSG?
• Work with HOKEY.
• Work with WGs for different media.
21-07-0297-00-0000
11
Inter-Media - Illustration
Authenticator
Peer
AS
MSK
EAP
MSK
EMSK
rRK-1
rRK-2
Re-Authentication (rMSK-1)
rMSK-1
rMSK-1
rMSK-2
rMSK-1
rMSK-2
Peer new
location
21-07-0297-00-0000
Peer-new
location
12
Possible Issues?
• EAP may not be used as an access authentication.
• Key hierarchy may not be available.
21-07-0297-00-0000
13
Problem 2
• Main goals
• Authentication needed to access the Services, e.g. Information Service;
and (this is also called access control.)
• Authorization on access to the service.
• Protect the Service data delivery.
• Main scenarios
• Authentication (EAP) server for network access is MIH aware.
•
•
•
Interface with e.g. the Information Server.
Access database for service subscription.
•
•
No interface with e.g. the Information Server.
Cannot access the database for service subscription.
Authentication (EAP) server for network access is not MIH aware
• Further Assumption
• Information Server access requires network access first*
* Any issues with this assumption?
21-07-0297-00-0000
14
Use Network Access Authentication
• Authentication Server accesses service
database to look up;
• For IS
•Use an IS-Key, derived in access
authentication/key establishment as
the Information Service root key;
•The IS-key is delivered to IS to
derive session keys for protection.
• 802.21 SSG tasks
•Specify key derivation algorithms;
•Specify message protection
algorithms (encryption, integrity
protection, etc).
AS
IS
Authenticator
Protected
information
service (802.21
SSG)
• Question – Any other tasks?
21-07-0297-00-0000
15
Independent Authentication for Service
• Need Service Specific Authentication
Server (maybe IS, ES, CS together).
(or IS will serve as an authentication
server).
• 802.21 tasks:
• Specify authentication methods
and/or protocols.
• Specify key establish methods
and/or protocols.
• Specify key derivation functions.
• Specify information protecting
algorithms.
21-07-0297-00-0000
AS
IS
Protected
information
service
16
Comparison and Issues?
• Which one is more realistic?
• Use network access authentication for Information Service
authentication;
•
•
•
•
•
•
Do not need new authentication protocol;
Information Service (IS) is integrated in the network landscape.
Only demand one authentication with one set of credentials.
EAP server must be IS aware.
May need modifications to the current EAP server.
Independent authentication for Information Service?
•
•
•
Can be added without demanding modifications to the EAP server.
Independent to existing media service and can work for any domain and
media.
Demand two authentications with two sets of credentials.
21-07-0297-00-0000
17
Use IS for Security (Problem 3)
• Can we use the Information Service to optimize security?
• For mobile nodes, use information service to get information
on
•
•
•
Authentication methods supported in targeted network;
Which points of attachment have received keys.
For authenticators
•
Where to distribute (push) the keys.
21-07-0297-00-0000
18
Other Security Issues to Work on?
• DoS attack mitigation mechanisms for service? (Michael Williams will
elaborate)
21-07-0297-00-0000
19
Summary
• Problem 1
• Inter-domain: Pre-authentication
• Intra-domain:
•
Inter-media:
–
•
–
If EAP is used as an access authentication and HOKEY hierarchy is available HOKEY
key hierarchy based handover (802.21 SSG works with HOKEY);
Otherwise, new work.
Intra-media: Media specific key hierarchy based handover (802.21 SSG works with
WGs in different media).
• Problem 2
• Use access authentication (require interface between AS/AAA and IS);
• Independent authentication.
• 802.21 SSG tasks on solving problem 2
• Specify authentication (if use independent authentication.)
• Specify information protection algorithms.
• Specify security information service.
• Problem 3 (802.21 SSG)
• Use Information Service to optimize security solutions.
21-07-0297-00-0000
20