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]