IEEE 802 21 MEDIA INDEPENDENT HANDOVER DCN 21

  • Slides: 22
Download presentation
IEEE 802. 21 MEDIA INDEPENDENT HANDOVER DCN: 21 -11 -0084 -01 -0000 Title: A

IEEE 802. 21 MEDIA INDEPENDENT HANDOVER DCN: 21 -11 -0084 -01 -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. 21 -11 -0084 -01 -0000 1

IEEE 802. 21 presentation release statements This document has been prepared to assist the

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 in Section 6 of the IEEE-SA Standards Board bylaws <http: //standards. ieee. org/guides/bylaws/sect 6 -7. html#6> and in Understanding Patent Issues During IEEE Standards Development http: //standards. ieee. org/board/pat/faq. pdf> 21 -11 -0084 -01 -0000 2

Outline • 802. 11 s Security • 802. 16 e Security • 802. 15

Outline • 802. 11 s Security • 802. 16 e Security • 802. 15 / Zig. Bee IP Security • Comparison 21 -11 -0084 -01 -0000 3

802. 11 s Security 21 -11 -0084 -01 -0000 4

802. 11 s Security 21 -11 -0084 -01 -0000 4

802. 11 s Overview • 802. 11 s defines MBSS (Mesh Basic Service Set)

802. 11 s Overview • 802. 11 s defines MBSS (Mesh Basic Service Set) for interconnecting 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. 11 s defines a new authentication mode called SAE (Simultaneous Authentication of Equals) 21 -11 -0084 -01 -0000 5

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

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 -01 -0000 6

Security Properties of SAE • • • The successful termination of the protocol results

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 -01 -0000 7

Computation of PWE for ECC group Elliptic Curve P Start counter=1; seed=H(MAX(MAC-A, MAC-B), MIN(MAC-A,

Computation of PWE for ECC group Elliptic Curve P Start 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 x<p && point (x, y) on Elliptic Curve P exists? Y PWE = (x, y) [if LSB(seed)==LSB(y)] (x, p-y) [ else ] End A given pair of Mesh STAs will compute the same PWE 21 -11 -0084 -01 -0000 8

SAE Protocol for ECC group • Each SAE protocol entity has two randomly generated

SAE Protocol for ECC group • Each SAE protocol entity has two randomly generated secrets; rand 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)=c. A • inverse(A): elem-op(A, inverse(A))=“point of infinity” • CN: confirmation function • CN(key, X, Y, Z, …) = HMAC-SHA 256(key, D 2 OS(X) || D 2 OS(Y) || D 2 OS(Z) || …) where D 2 OS 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, peercommit-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), PEERCOMMIT-ELEMENT))) • send-confirm: current value of the send-confirm counter • SAE also provides an option for Anti-Clogging token support to mitigate resource consumption Do. S attacks • After SAE, secure association using 802. 1 X is performed to establish 802. 11 MAC ciphering keys including multicast keys 21 -11 -0084 -01 -0000 9

SAE Call Flow without Anti-Clogging Token STA IEEE 802. 11 Probe Request IEEE 802.

SAE Call Flow without Anti-Clogging Token STA IEEE 802. 11 Probe Request IEEE 802. 11 Probe Response IEEE 802. 11 SAE Authentication [commit] IEEE 802. 11 SAE Authentication [confirm] IEEE 802. 11 SAE Authentication [confirm] 21 -11 -0084 -01 -0000 10

SAE Call Flow with Anti-Clogging Token STA IEEE 802. 11 Probe Request IEEE 802.

SAE Call Flow with Anti-Clogging Token STA IEEE 802. 11 Probe Request IEEE 802. 11 Probe Response IEEE 802. 11 SAE Authentication [commit] IEEE 802. 11 SAE Authentication [token] IEEE 802. 11 SAE Authentication [commit, token] IEEE 802. 11 SAE Authentication [commit] IEEE 802. 11 SAE Authentication [confirm] IEEE 802. 11 SAE Authentication [confirm] 21 -11 -0084 -01 -0000 11

802. 16 j Security 21 -11 -0084 -01 -0000 12

802. 16 j Security 21 -11 -0084 -01 -0000 12

802. 16 j Overview • 802. 16 j defines an extension to 802. 16

802. 16 j Overview • 802. 16 j defines an extension to 802. 16 for multi-hop relay operation • 802. 16 j 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 layer 21 -11 -0084 -01 -0000 13

802. 16 j Overview (cont’d) • Two RS types are defined • Transparent RSs

802. 16 j 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 -01 -0000 14

Security Modes SA between SS and MRBS SS RS RS MR BS Concentrated Mode

Security Modes SA between SS and MRBS SS RS RS MR BS Concentrated Mode SA between RS and MRBS SA between SS and RS SS RS RS MR BS Distributed Mode 21 -11 -0084 -01 -0000 15

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

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 • PKMv 2 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 -01 -0000 16

802. 15 / Zig. Bee IP Security 21 -11 -0084 -01 -0000 17

802. 15 / Zig. Bee IP Security 21 -11 -0084 -01 -0000 17

802. 15 Overview • 802. 15 is a mesh network standard for PAN (Personal

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 • Zig. Bee PRO (basis for Smart Energy 1. 0) • Zig. Bee IP (basis for Smart Energy 2. 0) • The subsequent slides provide a survey of Zig. Bee IP focusing on its security aspects (see also: http: //www. iab. org/about/workshops/smartobjects/tutorial/Cragie. pptx) 21 -11 -0084 -01 -0000 18

Zig. Bee IP (ZIP) Security • ZIP is defined using 6 Low. PAN •

Zig. Bee IP (ZIP) Security • ZIP is defined using 6 Low. PAN • 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 (Pa. C) can use only a link-local IPv 6 address for PANA • A 6 LBR (6 Lo. WPAN Border Router) acts as a PANA authentication agent (PAA) • The parent node acting as a PRE (PANA Relay Element) relays PANA messages between the Pa. C and PAA, the parent node acts as a PRE • A new PANA extension for the relay operation is being defined in IETF (draftohba-pana-relay) • After successful PANA authentication, a group key is securely unicast to the Pa. C 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 -01 -0000 19

PANA Relay EAP over PANA Using global IPv 6 addresses PAA Using link-local IPv

PANA Relay EAP over PANA Using global IPv 6 addresses PAA Using link-local IPv 6 addresses PRE Pa. C: PANA Client PRE: PANA Relay Element PAA: PANA Authentication Agent 21 -11 -0084 -01 -0000 20

Comparison 802. 11 s 802. 16 j Zig. Bee IP Network Access Authentication L

Comparison 802. 11 s 802. 16 j Zig. Bee IP Network Access Authentication L 2 (SAE) Layer L 2 (PKMv 2) L 3 (PANA) Authentication Infrastructure (AAA, PKI, etc. ) Not supported Supported Group Key Management Purpose Multicast L 2 frame protection Relay management frame protection L 2 key agreement between joining and parent nodes Distribution Method Unicast (ZSK) Unicast Multicast (ZSKEK) 21 -11 -0084 -01 -0000 21

Summary • Security mechanisms are significantly different among different mesh networking technologies in terms

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 mechanism 21 -11 -0084 -01 -0000 22