Transcript IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-0xxx-00-0000 Title: Proposal for adding a key hierarchy based approach in the security requirement document Date Submitted: November.

IEEE 802.21 MEDIA INDEPENDENT HANDOVER
DCN: 21-07-0xxx-00-0000
Title: Proposal for adding a key hierarchy based approach in the security
requirement document
Date Submitted: November 4, 2007
Presented at IEEE 802.21 session #23 in Atlanta
Authors or Source(s): Lily Chen, Katrin Hoeper, Antonio Izquierdo, Nada
Golmie
Abstract: This presentation is to propose a key hierarchy-based approach for
optimizing the security signaling in media independent handovers.
Companion text for the SSG requirements document is included in 21-07402-0000.doc)
21-07-0xxx-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.
TheThis
contributor
grants a free,
license
to the IEEE
to incorporate
is a contribution
byirrevocable
the National
Institute
of Standards
and
material
contained
in is
thisnot
contribution,
and
any
modifications
thereof,
inThe
the
Technology
and
subject
to
copyright
in
the
US.
creation of an IEEE Standards publication; to copyright in the IEEE’s name
contributors
do notpublication
have the even
authority
theportions
NIST policy
any IEEE Standards
thoughtoit override
may include
of this
in
favor of the
802.21sole
policy.
contribution;
and IEEE
at the IEEE’s
discretion to permit others to reproduce in
or in part
the resulting
IEEE patent
Standards
publication.
The
contributor
also
Thewhole
contributor
is familiar
with IEEE
policy,
as stated in
Section
6 of the
acknowledges
and accepts
that this contribution may be made public by IEEE
IEEE-SA Standards
Board bylaws
802.21.
<http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and in
During
IEEEpolicy,
Standards
Development
TheUnderstanding
contributor is Patent
familiarIssues
with IEEE
patent
as outlined
in Section 6.3 of
http://standards.ieee.org/board/pat/faq.pdf>
the IEEE-SA Standards Board Operations Manual
<http://standards.ieee.org/guides/opman/sect6.html#6.3> and in
Understanding Patent Issues During IEEE Standards Development
http://standards.ieee.org/board/pat/guide.html>
•
21-07-0xxx-00-0000
2
Abstract
• Applicable scenarios
• Why take a key hierarchy based approach
• How to use HOKEY key hierarchy for re-authentication
• Example message flow
21-07-0xxx-00-0000
3
Applicable scenario
Intra-tech
Inter-tech
Inter-tech
EAP to EAP
EAP to non-EAP
Intra-domain*
As defined in
the tech
specific key
hierarchy, like
802.11r or
3GPP
Inter-domain
Pre-authentication as proposed in contributions (#390, #403,
etc.)
* It includes inter-domain
with agreements
21-07-0xxx-00-0000
Hokey key
hierarchy
based (in this
contribution)
May need to
establish mapping
between different
key hierarchies
(For future study)
The is the scenario
discussed in this
proposal
4
Applicable scenarios – Intra-domain and Inter-tech
SA
EAP
Authentication
Server – for the
domain
MN
TA
21-07-0xxx-00-0000
5
Assumptions and Clarifications
• Assumptions:
• A full EAP authentication has been conducted with an authentication
server.
• A key hierarchy has been established based on HOKEY key hierarchy.
• Re-authentication
• Use established key in the key hierarchy;
• Shorter message exchanges;
• Can be conducted either proactively or reactively;
•
•
•
•
•
Proactively –before a signal loss.
Reactively –after a signal loss.
With multiple or single candidate authenticators;
Can be direct or indirect
Can be done over a pre-authentication transport
• Work to be done in 802.21 Security SG
• Provide network information, e.g. location of candidate authenticators
•
•
Same work is required for pre-authentication.
Indication of re-authentication capability support in 21 signaling.
21-07-0xxx-00-0000
6
Why take a key hierarchy based approach?
• Using the HOKEY key hierarchy and re-authentication optimize the security
signallings of handover (See presentation 21-07-0xxx-00-0000). The
advantages include
• Reduce the authentication latency.
• Execute as needed with potentially an target authenticator instead of
multiple authenticators.
• Save the computation costs and power consumption.
• Independent to EAP-method chosen.
• EAP has been adopted as an access authentication and also key
establishment protocol by commonly implemented wireless technologies,
e.g. 802.11 and 802.16.
• IETF HOKEY group has developed key hierarchy for handover (see
http://www.ietf.org/internet-drafts/draft-ietf-hokey-emsk-hierarchy-01.txt)
and the status of the key hierarchy is stable.
• Are there any reasons for excluding such an approach?
21-07-0xxx-00-0000
7
EAP key derivation
Peer
Authenticator
AS
EAP
MSK
21-07-0xxx-00-0000
MSK
EMSK
8
Use Hokey key hierarchy for Re-authentication
• Assume re-authentication root key
(rRK) is derived from EMSK*.
EMSK
• The integrity key (rIK) is used for
integrity protection in reauthentication exchange (and also
for implicit authentication).
• Re-authentication MSK (rMSK) is
delivered to target authenticator
and used as new MSK upon
successful re-authentication
rRK-1
rIK-1
rMSK-1
rRK-2
rIK-2
rMSK-2
*It may be derived from DSRK
(domain specific root key).
21-07-0xxx-00-0000
9
Re-authentication triggers rMSK delivery
Target
Authenticator
Peer
Re-Authentication (use rIK-1)
EAP ReAuth
Server (ERS)
rRK-1
rMSK-1
rMSK-1
Peer new
location
21-07-0xxx-00-0000
rIK-1
rMSK-1
For intra-authenticator
handover, it will follow
the intra-technology
scenario.
10
Example message flow
MN
TA
ERS*
[EAP Request/Identity]
[EAP Initiate/Reauth-start]
EAP Initiate/Reauth-start
EAP Initiate/Reauth-start
rMSK EAP Finish/Reauth
EAP Finish/Reauth
*ERS could be a local authentication server, which holds DS-rRK.
21-07-0xxx-00-0000
11
Summary
• Key hierarchy based approach is applicable to inter-technology
(EAP -> EAP) and intra-domain handovers.
• Re-authentication can be conducted with either the EAP server
or a local server which has obtained a rRK.
• Re-authentication optimizes security signaling during
handovers.
• Re-authentication can be conducted with the target
authenticator, instead of multiple candidate authenticators, so
that it reduces time and power consumption for handover.
21-07-0xxx-00-0000
12