IEEE 802.21 MEDIA INDEPENDENT HANDOVER

DCN: 21-11-0084-00-0000

Title: A Survey on Mesh Network Security

Date Submitted: May 16, 2011

Presented at IEEE 802.21 session #44 in Lake Louise

Authors or Source(s):

Yoshihiro Ohba (Toshiba) and Subir Das (Telcordia)

Abstract: This document provides a survey on security of existing mesh networking technologies.

121-11-0084-00-0000

21-11-0084-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 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> 

Outline• 802.11s Security

• 802.16e Security

• 802.15 / ZigBee IP Security

• Comparison

321-11-0084-00-0000

802.11s Security

21-11-0084-00-0000 4

802.11s Overview• 802.11s defines MBSS (Mesh Basic Service Set) for inter-

connecting Mesh STAs

• Mesh routing is done at MAC layer (i.e., mesh-under) using a modified version of AODV (Ad-hoc On-Demand Distance Vector)

• 802.11s defines a new authentication mode called SAE (Simultaneous Authentication of Equals)

21-11-0084-00-0000 5

What is SAE?• Simultaneous Authentication of Equals (SAE) is a variant of

Dragonfly, a password-authenticated key exchange based on a zero-knowledge proof.

• SAE is used by STAs to authenticate with a password and dynamically establish session keys

• SAE supports both FFC (Finite Field Cryptography) and ECC (Elliptic Curve Cryptography)

• By default, SAE uses ECC with order of 256-bit prime number.

21-11-0084-00-0000 6

Security Properties of SAE• The successful termination of the protocol results in a PMK shared

between the two STAs.• An attacker is unable to determine either the password or the

resulting PMK by passively observing an exchange or by interposing itself into the exchange by faithfully relaying messages between the two STAs.

• An attacker is unable to determine either the password or the resulting shared key by modifying, forging, or replaying frames to an honest, uncorrupted STA.

• An attacker is unable to make more than one guess at the password per attack. This implies that the attacker cannot make one attack and then go offline and make repeated guesses at the password until successful. In other words, SAE is resistant to dictionary attack.

• Compromise of a PMK from a previous run of the protocol does not provide any advantage to an adversary attempting to determine the password or the shared key from any other instance.

21-11-0084-00-0000 7

Computation of PWE for ECC group

counter=1;

seed=H(MAX(MAC-A,MAC-B), MIN(MAC-A,MAC-B), password, counter)x=KDF(seed, “SAE Hunting and Pecking”, p)

counter++;N

Y

x<p && point (x,y) on Elliptic Curve P exists?

PWE = (x,y) [if LSB(seed)==LSB(y)] (x,p-y) [ else ]

Start

End

Elliptic Curve P

A given pair of Mesh STAs will compute the same PWE821-11-0084-00-0000

SAE Protocol for ECC group• Each SAE protocol entity has two randomly generated secrets; rand and mask

• mask is a temporal secret to be changed for each SAE protocol run• SAE uses two messages; Commit and Confirm• SAE uses the following operations and functions;

• elem-op(A, B)=A+B• scholor-op(c,A)=cA• inverse(A): elem-op(A, inverse(A))=“point of infinity”• CN: confirmation function

• CN(key, X, Y, Z, …) = HMAC-SHA256(key, D2OS(X) || D2OS(Y) || D2OS(Z) || …) where D2OS is data to octet string function

• Commit message• commit-scholar = (rand + mask) mod r• COMMIT-ELEMENT=inverse(scholor-op(mask, PWE))

• Confirm message• confirm = CN(KCK, send-confirm, commit-scalar, COMMIT-ELEMENT, peer-

commit-scalar, 　 PEER-COMMIT-ELEMENT)• KCK || PMK = KDF-512(keyseed, “SAE KCK and PMK”, (commit-scalar +

peer-commit-scalar) modulo r)• keyseed = H(<0>32, k)• k=F(K) • K = scalar-op(rand, (elem-op(scalar-op(peer-commit-scalar, PWE), PEER-

COMMIT-ELEMENT)))• send-confirm: current value of the send-confirm counter

• SAE also provides an option for Anti-Clogging token support to mitigate resource consumption DoS attacks

• After SAE, secure association using 802.1X is performed to establish 802.11 MAC ciphering keys including multicast keys

21-11-0084-00-0000 9

SAE Call Flow without Anti-Clogging Token

STA STAIEEE 802.11 Probe RequestIEEE 802.11 Probe Response

IEEE 802.11 SAE Authentication [commit]IEEE 802.11 SAE Authentication [commit]

IEEE 802.11 SAE Authentication 　 [confirm]IEEE 802.11 SAE Authentication [confirm]

1021-11-0084-00-0000

SAE Call Flow with Anti-Clogging Token

STA STAIEEE 802.11 Probe RequestIEEE 802.11 Probe Response

IEEE 802.11 SAE Authentication 　 [commit]IEEE 802.11 SAE Authentication [token]

IEEE 802.11 SAE Authentication 　 [confirm]IEEE 802.11 SAE Authentication [confirm]

IEEE 802.11 SAE Authentication [commit, token]IEEE 802.11 SAE Authentication [commit]

1121-11-0084-00-0000

802.16j Security

21-11-0084-00-0000 12

802.16j Overview• 802.16j defines an extension to 802.16 for multi-hop relay

operation

• 802.16j defines the following types of nodes

• RS (Relay Station) : a node that resides between SS (Stationary Station) or MS (Mobile Station) and MR-BS to relay 802.16 frames in between

• MR-BS (Multi-hop Relay Base Station): an entity that can communicate with SS or (MS) through one or more RSs

• All data frames go through MR-BS

• A simple multi-hop relay routing is done at MAC layer21-11-0084-00-0000 13

802.16j Overview (cont’d)• Two RS types are defined

• Transparent RSs communicate with its parent and child nodes using the same frequency channel, supporting only 2 hops

• Non-transparent RSs communicate with parent and child nodes using different frequency channels, supporting more 2 or more hops

• Two modes of scheduling is defined for bandwidth resource management• In centralized scheduling mode, MR-BS manages the bandwidth

resource for SS/MS and RS• In distributed scheduling mode, the bandwidth allocation of an RS’s

subordinate stations is determined by the RS, in cooperation with the MR-BS

• Two forwarding modes are defined• In tunnel mode, data frames sent from/to SS/MS and MR-BS are

tunneled between Access RS (the closest RS to SS/MS) and MR-BS• In CID(connection ID) -based forwarding mode, each RS forwards data

frame based on CID assigned to each SS/MS

• Forwarding mode is determined by RS type, scheduling mode and # of hops between MR-BS and SS/BS

21-11-0084-00-0000 14

Security Modes

SS RS RSMRBS

SS RS RSMRBS

SA between SS and MRBS

SA between SS and RS SA between RS and MRBS

Concentrated Mode

Distributed Mode

1521-11-0084-00-0000

Security Zone• One MR-BS and its subsidiary RSs form a Security Zone with the following

properties

• An RS becomes a member of the Security Zone when it authenticates to the MR-BS and obtains a SZK (Security Zone Key) from the MR-BS

• PKMv2 is used for secure SZK distribution

• An SZK needs to be updated when a RS leaves the Security Zone

• A Security Zone Security Association has two keys, SZK and SZKEK

• SZK is used for protecting relay management frames• SZKEK is used for encrypting SZK

• SZK is multicast from MR-BS

• SZKEK is unicast from MR-BS

21-11-0084-00-0000 16

802.15 / ZigBee IP Security

21-11-0084-00-0000 17

802.15 Overview• 802.15 is a mesh network standard for PAN (Personal Area Network)

• 802.15 does not define a mesh routing protocol or • Higher-layer is supposed to provide a mesh routing protocol

• 802.15 does not define an authentication and key management protocol• Only provides MAC layer ciphering mechanisms• Higher-layer is supposed to provide an authentication and key

management protocol to dynamically generate 802.15 MAC layer ciphering keys

• Typical higher layers of 802.15 that define a mesh routing protocol and an an authentication and key management protocol

• ZigBee PRO (basis for Smart Energy 1.0)• ZigBee IP (basis for Smart Energy 2.0)

• The subsequent slides provide a survey of ZigBee IP focusing on its security aspects (see also: http://www.iab.org/about/workshops/smartobjects/tutorial/Cragie.pptx)

21-11-0084-00-0000 18

ZigBee IP (ZIP) Security• ZIP is defined using 6LowPAN

• In ZIP, RFC 5191 a.k.a PANA (Protocol for carrying Authentication for Network Access), an EAP transport protocol defined on top of UDP, is used for the network access authentication

• Before network access authentication, only PANA traffic can go through the parent node

• A joining node acting as a PANA Client (PaC) can use only a link-local IPv6 address for PANA

• A 6LBR (6LoWPAN Border Router) acts as a PANA authentication agent (PAA)

• The parent node acting as a PRE (PANA Relay Element) relays PANA messages between the PaC and PAA, the parent node acts as a PRE

• A new PANA extension for the relay operation is being defined in IETF (draft-ohba-pana-relay)

• After successful PANA authentication, a group key is securely unicast to the PaC from the

PAA• The group key is used for establishing MAC-layer ciphering keys to be used between

the joining node and parent node

21-11-0084-00-0000 19

PANA Relay

PAA PRE

PaC: PANA ClientPRE: PANA Relay ElementPAA: PANA Authentication Agent

PaC

EAP over PANA

Using global IPv6 addresses Using link-local IPv6 addresses

2021-11-0084-00-0000

Comparison

21-11-0084-00-0000 21

802.11s 802.16j ZigBee IP

Network Access Authentication Layer

L2 (SAE) L2 (PKMv2) L3 (PANA)

Authentication Infrastructure(AAA, PKI, etc.)

Not supported Supported Supported

Group Key Management

Purpose Multicast L2 frame protection

Multicast L2 frame protection

L2 key agreement between joining and parent nodes

DistributionMethod

Unicast Unicast (ZSK)Multicast (ZSKEK)

Unicast

Summary• Security mechanisms are significantly different among different

mesh networking technologies in terms of • authentication layer • authentication infrastructure support• Group key management

• Therefore, it may not be realistic to define a unified mesh security mechanism that replaces the security mechanisms defined in the existing mesh networking technologies

• On the other hand, it may make sense to have an add-on security mechanism that can work across those mesh networking technologies

• Proactive authentication can be such an add-on security mechanism21-11-0084-00-0000 22