21-08-0035-00-0sec IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-08-0035-00-0sec-802_1af_overview Title: 802.1af Overview Date Submitted: January 16,

21-08-0035-00-0sec

IEEE 802.21 MEDIA INDEPENDENT HANDOVER

DCN: 21-08-0035-00-0sec-802_1af_overview

Title: 802.1af Overview

Date Submitted: January 16, 2008

Presented at IEEE 802.21 session #24 in Taipei

Authors or Source(s):

 Yoshihiro Ohba (Toshiba)

Abstract: This document provides an overview of IEEE 802.1af - Media Access Control (MAC) Key Security

21-08-0035-00-0sec

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.

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 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-08-0035-00-0sec

What is 802.1af?

• 802.1af is an amendment to IEEE std 802.1X to establish security associations for 802.1ae MAC Security, and provide media access method independent association discovery

• 802.1af will facilitate secure communication over publicly accessible LAN/MAN media for which security has not otherwise been defined

• It is not the purpose of this standard to provide alternatives for the IEEE Std 802.11 specified functionality in 802.11 wireless networks.

• Latest 802.1af draft revision (as of 2008-Jan-7): 1.7

21-08-0035-00-0sec

What is defined in 802.1af

• The principles of port-based access control operation and functional components

• The key hierarchy used by the functional components

• An encapsulation format for EAP carried directly by a LAN MAC service

• A MAC Security Key Agreement protocol (MKA)

• MIBs

21-08-0035-00-0sec

Security Relationships

• secure Connectivity Association (CA): A security relationship, established and maintained by key agreement protocols, that comprises a fully connected subset of the service access points in stations attached to a single LAN that are to be supported by MACsec.

• Secure Association (SA): A security relationship that provides security guarantees for frames transmitted from one member of a CA to the others. Each SA is supported by a single secret key, or a single set of keys where the cryptographic operations used to protect one frame require more than one key.

• Secure Channel (SC): A security relationship used to provide security guarantees for frames transmitted from one member of a CA to the others. An SC is supported by a sequence of SAs thus allowing the periodic use of fresh keys without terminating the relationship.

21-08-0035-00-0sec

Functional Components

• Port Access Entity (PAE)• Support EAP as a Supplicant or as an Authenticator, or both• Support PACP (Port Access Control Protocol) to carry EAP

• Port Access Controller (PAC)• Support operation of the controlled Port

• MACsec Key Agreement Entity (KaY)• A part of PAE• Support the configuration and use of pre-shared keys• Support MKA (MACsec Key Agreement) protocol

• MAC Security Entities (SecY)• Secure each port using 802.1AE

• Management Entity• Support the system configuration and monitoring functions

Without further qualifications, PAE, PAC and Management Entity must be supported, and KaY and SecY may be supported (e.g., 802.11 does not support KaY and SecY)

21-08-0035-00-0sec

Architecture

MAC specificfunctions

PAC or SecY

LLC LLC

PAE

(M)

(U) (C)

( )

MACClients

( )

MAC specificfunctions

PAC or SecY

LLC LLC

PAE

(M)

(U) (C)

( )

MACClients

( )

Cryptographically secured communication (w/SecY only)

Secured access controlled communication

Authentication exchange using EAPoL

Peer discovery and key agreement Auth using EAP/RADIUS

Authz using RADIUS

-()- Port, -(U)- Uncontrolled Port, -(C)- Uncontrolled Port

21-08-0035-00-0sec

Architecture for shared LAN

MAC specific functions

PAE

(M)

PAC or SecY

LLC LLC(U) (C)

( )

MACClients

( )

MAC specificfunctions

PAC or SecY

LLC LLC

(M)

(U) (C)

( )

MACClients

( )

-()- Port, -(U)- Uncontrolled Port, -(C)- Uncontrolled Port, -(M)- Common Port

PAC or SecY

LLC LLC(U) (C)

( )

MACClients

( )

PAE

MAC specificfunctions

PAC or SecY

LLC LLC

(M)

(U) (C)

( )

MACClients

( )

PAE

Host HostNetwork Access Point

21-08-0035-00-0sec

Use Cases

a) [Simple] Host access using individual, physically secure LANs

b) [Infrastructure] Infrastructure support with physically secure LANs

c) [Secure] Host access using MACsec

d) [Secure Infrastructure] Infrastructure LANs using MACsec

e) Group host access using MACsec

21-08-0035-00-0sec

“Simple” Use Case

AS

Network Access Point

Physically secureAccess LAN

Secured network

Host

21-08-0035-00-0sec

“Infrastructure” Use Case

AS

Physically secure LAN

Secured networkSecured network

Secured network

Intermediate Systems

21-08-0035-00-0sec

“Secure” Use Case

AS

Shared-access LANwith MACsec

Secured network

Hosts

AS

Network Access Point

P-P access LANwith MACsec

Host

Pair-wise CAs

Pair-wise CA

21-08-0035-00-0sec

“Secure Infrastructure” Use Case

AS

P-P LAN with MACsec

Secured networkSecured network

Secured network

Intermediate Systems

ASSecured network

Pair-wise CAs

Secured networkShared-access LAN with MACsec

Secured network

21-08-0035-00-0sec

“Group host access” Use Case

AS

Shared access LANwith MACsec

Secured network

Hosts

Network Access Point

Group CA

21-08-0035-00-0sec

System conformance claim

Conformance claim (use case)

PAE PAC KaY SecY Management

Simple

(unqualified)

Required Required Required

Infrastructure Required Required Required

Secure Required Required Required Required

Secure infrastructure

Required

PSK required

Required Required

PAC and SecY are exclusively used for a given CAEach CA may support different use case

21-08-0035-00-0sec

Key Management Overview• Key hierarchy

• A root key, or a CAK (Connection Association Key), is shared between stations in a CA

• Pair-wise CAK for pair-wise CA• Group CAK for group CA (for “group host access” use case)

• Keys for protecting key distribution are derived from a CAK• ICK (ICV Key)• KEK (Key Encrypting Key)

• A pair-wise CAK may be a pre-shared key (PSK)• By default, MKA gives precedence to the use of CAKs generated by EAP and then to PSKs

• Key distribution• The following keys can be distributed using a CAK:

• SAK (Security Association Key) • Group CAK

• Key distribution protocol: MKA (MACsec Key Agreement) protocol• MKA is carried in EAPOL-MKA packet

• Key caching• A CAK may be cached for later use• Cached CAKs are shared among systems in the same Key Management Domain• While a Key Management Domain can comprise more than one system, how a

number of systems hold a CAK in common or convey it to the particular system that requires it to support roaming is outside the scope of 802.1af

21-08-0035-00-0sec

MKA Key Hierarchy

SAK

Distributed SAK

Key Server rng()

CAK: Connectivity Association KeyICK: ICV KeyKEK: Key Encrypting KeySAK: Secure Association KeyECB: Electronic Code Book rng: random number generator

CAK

ICK KEK

+

ECB

Key W

rap

ECB

MKAIntegrity

21-08-0035-00-0sec

Use of Pair-Wise CAKs to distribute Group SAKs(for “Group host access” Use Case)

Group CAK

Distributed Group CAK

CAK

ICK KEK

+

ECB

Key W

rap

ECB

MKAIntegrity

Key Server rng()

ICK

CAK

KEK

+

ECB

Key W

rap

ECB

MKAIntegrity

ICK KEK

+

ECB

Key W

rap

ECB

MKAIntegrity

Distributed SAK

SAK

Key Server rng()

21-08-0035-00-0sec

Network Discovery and Selection

• Network discovery• A PAE may advertise information about the network(s) for which it

controls access• A PAE may solicit advertisements from the PAEs of other systems

attached to the same LAN• Advertisements and solicitations are conveyed in EAOPL PDUs• Information about the network(s):

• NID (Network Identity)• Whether the advertising PAE supports PACP and/or MKA• Whether fallback, unauthenticated, unsecured, and limited connectivity is provided • Whether authentication is supported by a higher layer protocol (such as WebAuth)• Key Management Domain identifier

• Network selection• A Supplicant PAE may select the network to be accessed, by choosing

to send unicast PACP PDUs over the port advertising the preferred network

• If a single port has advertised access to several networks, where each network is associated with a VLAN, the Supplicant can make its choice by using the appropriate VLAN for the PACP PDUs

• A given system can be attached to one of many LANs, with its potential peer or peers providing access to many different networks.

21-08-0035-00-0sec

Roaming

• “A given system can also be moved (roam) from one network to another before being reconnected (roaming) to the first”

• “In that case communication can be re-established quickly if both communicating PAEs have cached the results of a prior mutual authentication”

• “Peer discovery and key agreement can be used to confirm the authentication and use it to agree fresh keys to protect data transfer, while a fresh authentication exchange with the AAA server is in progress”

• A cached CAK cannot be used across multiple Key Management Domains

21-08-0035-00-0sec

Requirements on EAP methods for 802.1af

• Mutual authentication must be supported

• When 802.1AR Secure Device Identifier is used:• EAP-TLS with TLS_RSA_WITH_AES_128_CBC_SHA

ciphersuite must be supported

• When MKA is used:• Additional mandatory features:

• Support key derivation. The strength of the derived keys should be at least equivalent to 128 bits

• Generate a session identifier• Recommended features:

• Integrity/Replay protection, Dictionary attack protection, cryptographic binding, session independence, fragmentation, Ciphersuite negotiation, Confidentiality, Fast reconnect, Channel binding

• When the EAP Supplicant represents a human user, identity protection should be provided

21-08-0035-00-0sec

PACP (Port Access Control Protocol)

• Support EAP Peer and/or EAP Authenticator functionality

• Transmission and reception of EAPOL PDUs, including the dynamic creation of virtual ports, between Supplicant and Authenticator PAEs

• Encoding, decoding, and validation of EAPOL PDUs

21-08-0035-00-0sec

EAPOL PDU

• Transmitted and received using the service provided by an LLC entity that uses, in turn, a single instance of the MAC Service provided at an MSAP, using Ehertype 88-8E

• Each EAPOL PDU is transmitted as a single MAC service request, and received as a single MAC service indication

• Source address: individual address

• Destination address : individual address or group address• Where a group destination address is used, the choice of

address depends on the potential scope of the CA• A scope can be:

• a single LAN segment• the whole of a bridged LAN

21-08-0035-00-0sec

EAPOL Packet Types

Packet Type Value Recipient Entity

EAP-Packet 0000 0000 PAE/PACP

EAPOL-Start 0000 0001 PAE/PACP

EAPOL-Logoff 0000 0010 PAE/PACP

EAPOL-Key 0000 0011 Determined by the Descriptor Type

EAPOL-Encapsulated-ASF-Alert 0000 0100 ASF-Helper

EAPOL-MKA 0000 0101 PAE/MKA

21-08-0035-00-0sec

Relationship with 802.21

• SSOH (security signaling optimization during handovers) being studied in 802.21 Security SG is applicable to support secure seamless handovers:

• between 802.11 network and 802.1af-enabled network• between 802.16 network and 802.1af-enabled network• between 802.1af-enabled networks across 802.1af Key

Management Domains

• These use cases need to work across multiple LANs while 802.1 architecture is defined within a single LAN