Internet DRAFT - draft-avula-shwmp
draft-avula-shwmp
Independent Submission M. Avula
Internet Draft S. M. Yoo
Intended status: Experimental University of Alabama in Huntsville
Expires: September 13, 2014 S. G. Lee
Dongseo University
March 13, 2014
Secure Hybrid Wireless Mesh Protocol (SHWMP)
<draft-avula-shwmp-01.txt>
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 13, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Abstract
Secure Hybrid Wireless Mesh Protocol (SHWMP) for a Wireless Mesh
Network (WMN) is a modified version of Hybrid Wireless Mesh Protocol
(HWMP) which ensures both end-to-end and point-to-point
authentication and integrity by using ID based signature schemes and
key agreement schemes.
Avula, et al. Expires September 13, 2014 [Page 1]
Internet Draft shwmp-internet-draft March 13, 2014
Table of Contents
1. Introduction ....................................................2
2. Preliminary notes ...............................................3
2.1. Security requirement of WMN ................................3
2.2. Security features of secure HWMP............................3
3. Overview of secure HWMP .........................................4
4. Terminology .....................................................6
5. Message formats .................................................6
5.1. PREQ Message Extension .....................................6
5.2. PREP Message Extension .....................................7
5.3. PERR Message Extension .....................................8
5.4. RANN Message Extension .....................................9
5.5. GANN Message Extension ....................................10
6. Secure HWMP Operation ..........................................12
6.1. Non-mutable field protection ..............................12
6.2. Mutable field protection ..................................12
7. Security Considerations.........................................13
8. IANA Considerations.............................................14
9. References......................................................14
1. Introduction
In an 802.11 based Wireless Mesh Network (WMN), the basic routing
protocol is Hybrid Wireless Mesh Protocol (HWMP). HWMP is vulnerable
to several routing attacks such as wormhole attacks, routing disruption
attacks, flooding attacks etc. These attacks target the mutable fields
of the frames exchanged in this protocol which change at every
intermediate node and are prone to modification by malicious nodes.
In HWMP [5], there are routing messages (frames) that are used for
finding a route from source to destination. These frames require
security mechanisms to prevent external and internal attacks. End-to-
end encryption schemes can be employed to prevent external attacks.
The real challenge in a WMN lies in preventing internal attacks.
These frames contain two types of fields: mutable and non-mutable.
Mutable fields are those that get changed at every hop of their
journey. Therefore, the mutable fields require authentication at
every hop in order to prevent illegal modification or deletion
attacks. This can be achieved by employing a low cost two-hop
authentication method where a two-hop neighbor will check if the node
at previous hop has illegally modified the contents of the frame.
This will also ensure that no malicious nodes impersonate as a legal
node and be able to modify the contents of the frame. Non-mutable
fields are not modified at every hop of the journey. Therefore, an
end-to-end authentication using a signature scheme should be enough
to prevent external attacks.
SHWMP is a secure version of HWMP that uses cryptographic schemes to
Avula, et al. Expires September 13, 2014 [Page 2]
Internet Draft shwmp-internet-draft March 13, 2014
protect the routing messages by providing authentication and
integrity security features. It uses ID based signature and broadcast
encryption with non-interactive key agreement schemes to protect the
non-mutable and mutable fields of HWMP in a WMN.
2. Preliminary notes
This section describes the security requirements of a WMN and also
lists the security features provided by SHWMP. HWMP is the basic
routing protocol of a WMN and this paper discusses the protection of
HWMP routing messages but not the data messages.
2.1. Security requirement of WMN
Simultaneous Authentication of Equals (SAE) and 802.1x authentication
protocols are some of the security services for authentication of
HWMP frames that can be applied to prevent external attacks in a WMN.
Message integrity code can be used to ensure the integrity of the
contents of a HWMP frame. On the other hand, algorithms like Advanced
Encryption Standard (AES) can help protect the confidentiality.
External attacks can be detected by using end-to-end based security.
The major problem that is plaguing the WMNs is the detection of
internal attacks. Internal attacks might involve modification of
contents of the HWMP frame such as hop count and air time metric.
Some of the fields of a HWMP frame get modified at every hop while
others stay the same throughout their journey to the destination. For
those fields that do not change, end-to-end security service such as
a signature scheme should be enough to ensure protection. However,
the fields that get changed is quite important to provide link-to-
link based security so that every node along the journey should
authenticate the frame before passing it on. This ensures that the
contents of the frame are not modified and the frames can get dropped
if they are modified.
2.2. Security features of Secure HWMP
With regard to the security requirements discussed in the previous
section, a secure version of HWMP is proposed with the following
security features. These security features address the security of
the two types of fields in a HWMP frame. Non-mutable fields are those
fields which do not change from source to destination. Therefore,
SHWMP used an ID based signature scheme to authenticate non-mutable
fields. This scheme is a good candidate because the signer does not
need to have a signed public-key certificate to be verified by other
entities to verify the signatures generated by the signer. The public
key is derived from the user's identity information such as a MAC
address and a Private Key Generator (PKG) generates a corresponding
Avula, et al. Expires September 13, 2014 [Page 3]
Internet Draft shwmp-internet-draft March 13, 2014
private key from a master secret key.
For the mutable fields' protection, a multi-source broadcast
encryption scheme using probabilistic key distribution is used. This
scheme will let multiple nodes to broadcast secrets without using
asymmetric cryptographic primitives. Broadcast Encryption (BE) is a
technique used to provide secret keys to a set of privileged members
revoking access to other members of the network. The main idea behind
using this scheme is that a key distribution center (KDC) will
allocate a subset of keys to every node in the network from a total
set of keys using a probabilistic key pre-distribution scheme.
3. Overview of SHWMP
The solution proposed in this draft is a modified version of the HWMP
wherein the HWMP routing frames have extensions to provide security
features such as authentication and integrity.
When a Path Request (PREQ) frame is generated by a source node, the
non-mutable fields of the default PREQ frame are signed using an
online/offline ID based signature scheme [1] and the signature is
included in the message extension of the frame. Since non-mutable
fields do not change at every hop, intermediate node authentication
is not necessary and therefore the source node signs the non-mutable
fields of the HWMP PREQ frame such as addresses and sequence numbers
of originator and targets, lifetime, flags, PREQ ID, Element ID,
Length and Target Count. The message extension also consists of a top
hash value which is a random value hashed 'n' times, previous node
metric which is nothing but the metric value of the previous node and
a hash value corresponding the current hop count which is generated
by applying hash function over maximum hop count, top hash and shared
key between source and destination. Finally, Hashed Message
Authentication Code (HMAC) is also appended to the message extension
for the purpose of two-hop authentication using broadcast encryption
mechanism [2]. This HMAC is hashed over a broadcast secret which is
not available to the one-hop neighbor of the source as per the
broadcast encryption scheme. Only the two-hop neighbor of the
originator of the PREQ will be able to decrypt the HMAC. The entire
PREQ is encrypted by the source node with a one-hop shared key which
is used by its neighbor to decrypt when the source broadcasts this
PREQ. The one-hop neighbor node will decrypt the PREQ generated by
the source, increments the hop count, updates metric and previous
node metric, and broadcasts it by encrypting using its one-hop secret
key that it had shared with its one-hop neighbors as well. Note that
it does not have access to source's broadcast secret. When the
current node re-broadcasts the PREQ, it reaches the two-hop neighbor
of the source node. This two-hop neighbor will have the broadcast
secret as per the broadcast encryption and so will be able to access
Avula, et al. Expires September 13, 2014 [Page 4]
Internet Draft shwmp-internet-draft March 13, 2014
the HMAC and verify if the intermediate node has illegally modified
contents of the PREQ. This provided for two-hop authentication. If
everything is verified, this node will increment the hop count,
update the metric, previous node metric, and appends a new HMAC and
re-broadcasts it. This process repeats until the PREQ reaches the
destination or one of the nodes knows a route to the destination.
Pairwise transient keys are distributed using non-interactive key
agreement scheme. These keys can be used when a Path Reply (PREP)
frame needs to be generated by the destination/intermediate node.
HMAC can be applied to mutable fields using these keys and appended
to the message extension of a PREP. When the destination node
receives a PREQ, it can unicast the PREP to the source because it is
aware of the route to the source. PREP message extension is similar
to PREQ except that HMAC uses the pairwise keys generated by non-
interactive key agreement scheme. In case an intermediate node
already has a route to the destination due to its previous encounter
with either a PREQ or the PREP from the destination, it can generate
a PREP to be unicasted to the source if the Destination Only (DO)
flag is not set in the PREQ frame and if the last known sequence
number of the destination in the PREQ it just received is lower than
the sequence number of the destination the intermediate possesses in
its route cache. Ideally, this process of intermediate node replying
to a PREQ is basically an extension to the regular PREP reply process
except that in this case the intermediate node fetches an extra step
for authentication and verification purposes by contacting the
adjacent node in the route to the destination.
In case a node finds a broken link, it will generate a Path Error
(PERR) message to its precursor node informing the broken link. The
message extension field of PERR consists of signature of the non-
mutable fields using online/offline ID based signature scheme and
Time-To-Live (TTL). The whole PERR frame is encrypted using a
Pairwise Master Key (PMK) generated by a mechanism known as
Simultaneous Authentication of Equals (SAE).
When a mesh station is generating and sending a Gate Announcement
(GANN) frame announcing itself as the mesh gate, the gate
announcement gets propagated in the network similar to a PREQ.
Therefore, the frame flow of a GANN and a Root Announcement (RANN) is
similar to a PREQ except that there is no set destination in the
GANN/RANN because it is an announcement to all the mesh nodes. The
message flow of a RANN is very similar to that of a GANN except that
the mutable fields of a RANN in the message extension field include
metric and previous node metric.
Avula, et al. Expires September 13, 2014 [Page 5]
Internet Draft shwmp-internet-draft March 13, 2014
4. Terminology
This memo uses the conventional meanings [3] for the capitalized
words MUST, SHOULD and MAY. It also uses terminology taken from the
specifications of AODV and IPSec [4].
5. Message formats
This section describes proposed message extensions of the standard
HWMP routing messages. The original HWMP message formats are not
described here but only the extensions to them which are used for
providing security features are described in the following sub-
sections.
5.1. PREQ Message Extension
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PNM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Top Hash |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 1
Length The length of type specific data, not including the Type
and Length fields.
Reserved Reserved for future use.
PNM This indicated the metric of the node at the previous
hop.
Top Hash The top hash for the hop count authentication. This is
Avula, et al. Expires September 13, 2014 [Page 6]
Internet Draft shwmp-internet-draft March 13, 2014
the result of hashing an initial value 'n' times, where
'n' is the maximum hop count.
Hash This is the hashed value corresponding to the actual hop
count of the current node under consideration.
Signature This is the signature of the non-mutable fields of the
HWMP frame that is obtained by using ID based signature
scheme. The three bits of this signature in addition to
the 60 bytes denote that only x-coordinates of the points
on an elliptic curve are used. The ID based signature
scheme is based on elliptic curve cryptography.
HMAC This is the Hashed Message Authentication Code generated
by using the Multi-Source Broadcast Encryption scheme.
5.2. PREP Message Extension
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PNM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Top Hash |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 2
Length The length of type specific data, not including the Type
and Length fields.
Reserved Reserved for future use.
PNM This indicated the metric of the node at the previous
hop.
Avula, et al. Expires September 13, 2014 [Page 7]
Internet Draft shwmp-internet-draft March 13, 2014
Top Hash The top hash for the hop count authentication. This is
the result of hashing an initial value 'n' times, where
'n' is the maximum hop count.
Hash This is the hashed value corresponding to the actual hop
count of the current node under consideration.
Signature This is the signature of the non-mutable fields of the
HWMP frame that is obtained by using ID based signature
scheme. The three bits of this signature in addition to
the 60 bytes denote that only x-coordinates of the points
on an elliptic curve are used. The ID based signature
scheme is based on elliptic curve cryptography.
HMAC This is the Hashed Message Authentication Code generated
by using the Multi-Source Broadcast Encryption scheme.
5.3. PERR Message Extension
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 3
Length The length of type specific data, not including the Type
and Length fields.
Reserved Reserved for future use.
Signature This is the signature of the non-mutable fields of the
HWMP frame that is obtained by using ID based signature
scheme. The three bits of this signature in addition to
the 60 bytes denote that only x-coordinates of the points
on an elliptic curve are used. The ID based signature
scheme is based on elliptic curve cryptography.
HMAC This is the Hashed Message Authentication Code generated
Avula, et al. Expires September 13, 2014 [Page 8]
Internet Draft shwmp-internet-draft March 13, 2014
by using the Multi-Source Broadcast Encryption scheme.
5.4. RANN Message Extension
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PNM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Top Hash |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 4
Length The length of type specific data, not including the Type
and Length fields.
Reserved Reserved for future use.
PNM This indicated the metric of the node at the previous
hop.
Top Hash The top hash for the hop count authentication. This is
the result of hashing an initial value 'n' times, where
'n' is the maximum hop count.
Hash This is the hashed value corresponding to the actual hop
count of the current node under consideration.
Signature This is the signature of the non-mutable fields of the
HWMP frame that is obtained by using ID based signature
scheme. The three bits of this signature in addition to
the 60 bytes denote that only x-coordinates of the points
on an elliptic curve are used. The ID based signature
scheme is based on elliptic curve cryptography.
Avula, et al. Expires September 13, 2014 [Page 9]
Internet Draft shwmp-internet-draft March 13, 2014
HMAC This is the Hashed Message Authentication Code generated
5.5. GANN Message Extension
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Top Hash |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 5
Length The length of type specific data, not including the Type
and Length fields.
Reserved Reserved for future use.
Top Hash The top hash for the hop count authentication. This is
the result of hashing an initial value 'n' times, where
'n' is the maximum hop count.
Hash This is the hashed value corresponding to the actual hop
count of the current node under consideration.
Signature This is the signature of the non-mutable fields of the
HWMP frame that is obtained by using ID based signature
scheme. The three bits of this signature in addition to
the 60 bytes denote that only x-coordinates of the points
on an elliptic curve are used. The ID based signature
scheme is based on elliptic curve cryptography.
HMAC This is the Hashed Message Authentication Code generated
The most important security feature of a path discovery process is to
use cryptographic methods and provide authentication of non-mutable
Avula, et al. Expires September 13, 2014 [Page 10]
Internet Draft shwmp-internet-draft March 13, 2014
and mutable fields of the frame. This is accomplished by adding
message extension fields to the HWMP path selection frame elements
such as PREQ, PREP, GANN, RANN and PERR. The mesh station receiving
the frame will be able to identify if the frame is accompanied by an
extension by observing the flags field of the corresponding type of
element. For example, the PREQ element format has Flags field which
is eight bits long (B0:B7). Bits B3-B5 and B7 are reserved in general
and thus, can be used in our case to notify the receiver of the
existence of an extension field to the incoming frame. Similarly,
PREP and PERR elements have Flags field which has B0-B5 and B7 bits
reserved which can be used for the same purpose as mentioned above.
Also, RANN and GANN elements have B1 through B7 and B0 through B7
bits reserved, respectively that can be used for notification of
message extension fields.
NAME LENGTH(bytes) DESCRIPTION
Type 1 1 - PREQ
2 - PREP
3 - PERR
4 - RANN
5 - GANN
Length 1 The length of type specific data, not
including the Type and Length fields
Reserved 2 For future use
Top Hash 20 The top hash for the hop count
authentication.
PNM 4 Previous Node Metric
Hash 20 The hash corresponding to the actual hop count.
HMAC 20 HMAC for Mutable Fields using Multi-Source
Broadcast Encryption scheme
Signature 60 + 3bits The signature for Non-Mutable Fields using ID
based scheme
Similarity of message extensions: Both PREP and RANN message
extensions are the same as PREQ message extension. PERR message
extension is the same as PREQ message extension except that PNM, Top
Hash, and Hash fields are not required. GANN message extension is the
same as PREQ message extension except that PNM is not required.
Avula, et al. Expires September 13, 2014 [Page 11]
Internet Draft shwmp-internet-draft March 13, 2014
6. Secure HWMP Operation
This section describes how SHWMP verifies authentication and
integrity of the routing messages. Routing messages are secured based
on the field type. Both mutable and non-mutable fields use different
schemes for security.
6.1 Non-mutable field protection
The following are the non-mutable fields of the PREQ frame used for
path discovery process by mesh stations: Element ID, Length, Flags,
Hop Count, Element TTL, Path Discovery ID, Originator Mesh Station
Address, Originator HWMP Sequence Number, Originator External
Address, Lifetime, Metric, Target Count, Per Target Flags, Target
Address and Target Sequence Number.
These fields need to be provided with end-to-end security from a
source node to a destination node from illegal modification by
intermediate nodes. In this case, end-to-end security is sufficient
because these fields do not change from hop to hop and therefore,
this offline/online signature scheme can be used to sign these fields
by the source node requesting the route and can be verified by the
destination node to ensure the integrity of the non-mutable fields.
Using an ID based offline/online signature scheme detects the illegal
modification of non-mutable fields of HWMP frames by malicious
intermediate nodes and thus, it avoids potential internal attacks.
Therefore, this scheme provides integrity assurance of non-mutable
fields from the intermediate nodes on the transmission path to
protect non-mutable field modification attacks.
6.2 Mutable field protection
The proposed approach for securing mutable fields in route discovery
process uses symmetric cryptographic primitives. Usually, broadcast
encryption schemes are assumed to have single source broadcasting to
multiple receivers. However, the proposed approach applies a
broadcast encryption technique that has been adapted to support
multiple sources thus, making it a good candidate for the HWMP
protocol. An offline Key Distribution Center (KDC) is assumed to have
distributed secrets to every node for establishing, between nodes,
pairwise secrets and it is also assumed that the KDC has distributed,
to every node, authentication and verification schemes of a multi-
source broadcast encryption scheme. The source node uses Group
Temporal Key (GTK) as the one-hop group secret (KS), encrypts it with
its Pairwise Master Key (PMK) generated by Simultaneous
Authentication of Equals (SAE) authentication protocol and delivers
it to its one-hop neighbors. SAE is a peer-to-peer mutual
Avula, et al. Expires September 13, 2014 [Page 12]
Internet Draft shwmp-internet-draft March 13, 2014
authentication protocol which assumes that the nodes in the network
already possess a pre-shared common password. A PMK generated by this
protocol is shared between any given two nodes trying to authenticate
and is used to encrypt the secret randomly selected by the nodes
(say, in this case, KS). The source node also provides a Broadcast
Encryption (BE) message (BS) which includes its encrypted broadcast
secret TS. All one-hop neighbors of the source do revoked access to
broadcast secret. One-hop neighbors of the source are expected to
relay the BE message they receive to their one-hop neighbors. The
two-hop neighbors of the source will be able to verify the integrity
of BS that they receive with the pre-distributed broadcast keys that
they possess already. This scheme ensures that a node securely
recognizes its two-hop neighbors without having to trust one-hop
neighbors. Any two-hop neighbor of the source that receives BS will
be able to extract TS and verify that the previous node from which it
received BS did not have access to TS. By verifying the HMAC in the
BE message, it can verify the integrity of the message as well.
7. Security Considerations
In the ID based signature scheme used in SHWMP, the hassle of
requiring a pairing operation for signature generation/verification
can be avoided. Also, no certificates are required to be attached to
the signature for verification and no secret key information is
required as it is generated by the Private Key Generator (PKG). The
integrity of non-mutable fields can be verified at the destination
using the ID based signature scheme.
The shared key between the two end points of communication prevents
the illegal deletion of nodes from the network. Non-interactive key
agreement scheme prevents the eavesdropping attacks as the mutual
keys are derived without any interaction between the communicating
nodes.
Broadcast encryption provides two-hop authentication which avoids any
illegal modification of the contents of the frame and prevents non-
authenticated nodes from joining the network unless they collude.
Hashing at every intermediate node provides an additional layer of
security.
When the most known attacks can be avoided, replay attacks are still
subjects of various research works due to their easy technique based
on recording and re-sending a valid signed messages in the network.
The detection of compromised nodes in a WMN is a vast research area
and is out of the scope of this draft. SHWMP mostly focuses on
security verification rather than malicious node detection and
elimination. If a malicious node gets access to the common shared
keys or if a healthy node turns rogue, the node must be detected and
Avula, et al. Expires September 13, 2014 [Page 13]
Internet Draft shwmp-internet-draft March 13, 2014
quarantined from the network.
8. IANA Considerations
This document contains no actions for IANA.
9. References
[1] Joseph K. Liu, Joonsang Baek, Jianying Zhou, Yanjiang Yang, and
Jun Wen Wong. 2010. Efficient online/offline identity-based signature
for wireless sensor network. Int. J. Inf. Secur. 9, 4 (August 2010),
287-296.
[2] M. Ramkumar, "Broadcast Encryption with Probabilistic Key
Distribution and Applications," Journal of Computers, June 2006.
[3] S. Bradner: Key words for use in RFCs to Indicate Requirement
Levels. RFC 2119, March 1997.
[4] S. Kent, R. Atkinson: Security Architecture for the Internet
Protocol. RFC 2402, November 1998.
[5] IEEE Standard for Information technology--Telecommunications and
information exchange between systems--Local and metropolitan area
networks--Specific requirements Part 11: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) Specifications Am," IEEE
Standard for Information technology--Telecommunications and information
exchange between systems--Local and metropolitan area networks--Specific
requirements Part 11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications Am , vol., no., pp.,
Authors' Addresses
Mallikarjun Avula
Dept. of Electrical & Computer Engineering
The University of Alabama in Huntsville
301 Sparkman Dr
Huntsville, AL 35899
EMail: ma0004@uah.edu
Seong-Moo Yoo
Dept. of Electrical & Computer Engineering
The University of Alabama in Huntsville
301 Sparkman Dr
Huntsville, AL 35899
EMail: yoos@uah.edu
Sang-Gon Lee
Division of Computer & Information Engineering
Dongseo University
47 Jurye-ro, Sasang-gu
Busan, 617-716, Korea
EMail: nok60@dongseo.ac.kr
Avula, et al. Expires September 13, 2014 [Page 14]