21-07-0xxx-00-0000

1

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-07-402-0000.doc)

21-07-0xxx-00-0000

2

IEEE 802.21 presentation release statementsThis 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 outlined in Section 6.3 of 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 > 

IEEE 802.21 presentation release statementsThis 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.

•This is a contribution by the National Institute of Standards and Technology and is not subject to copyright in the US. The contributors do not have the authority to override the NIST policy in favor of the IEEE 802.21 policy.

The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws <http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/faq.pdf> 

21-07-0xxx-00-0000

3

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

4

Applicable scenario

Intra-tech

Intra-domain*

Inter-domain

Inter-tech

EAP to EAP

Inter-tech

EAP to non-EAP

As defined in the tech specific key hierarchy, like 802.11r or 3GPP

Hokey key hierarchy based (in this contribution)

May need to establish mapping between different key hierarchies (For future study)

* It includes inter-domain with agreements

The is the scenario discussed in this proposal

Pre-authentication as proposed in contributions (#390, #403, etc.)

21-07-0xxx-00-0000

5

Applicable scenarios – Intra-domain and Inter-tech

MN

SA

TA

Authentication Server – for the domain

EAP

21-07-0xxx-00-0000

6

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

7

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

8

EAP key derivation

EAP

Peer Authenticator AS

MSK MSK EMSK

21-07-0xxx-00-0000

9

Use Hokey key hierarchy for Re-authentication

• Assume re-authentication root key (rRK) is derived from EMSK*.

• The integrity key (rIK) is used for integrity protection in re-authentication 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 rRK-2

rMSK-2rMSK-1

EMSK

rIK-1 rIK-2

*It may be derived from DSRK (domain specific root key).

21-07-0xxx-00-0000

10

Re-authentication triggers rMSK delivery

Peer Target Authenticator EAP ReAuth

Server (ERS)

rRK-1

rMSK-1

Re-Authentication (use rIK-1)

rMSK-1

rMSK-1

Peer -new

location

rIK-1

For intra-authenticator handover, it will follow the intra-technology scenario.

21-07-0xxx-00-0000

11

Example message flow

MN TA ERS*

[EAP Request/Identity]

[EAP Initiate/Reauth-start]

EAP Initiate/Reauth-startEAP 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

12

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.