ROLL Working Group                                                Y. Qiu
Internet-Draft                                                   J. Zhou
Expires: April 25, 2013                                           F. Bao
                                         Institute for Infocomm Research
                                                        October 22, 2012


Lightweight Key Establishment and Management Protocol in Dynamic Sensor
                            Networks (KEMP)
                         draft-qiu-roll-kemp-02

Abstract

   When a sensor node roams within a very large and distributed wireless
   sensor network, which consists of numerous sensor nodes, its routing
   path and neighborhood keep changing.  In order to provide a high
   level of security in this environment, the moving sensor node needs
   to be authenticated to new neighboring nodes as well as to establish
   a key for secure communication.  The document proposes an efficient
   and scalable protocol to establish and update the secure key in a
   dynamic wireless sensor network environment.  The protocol guarantees
   that two sensor nodes share at least one key with probability 1
   (100%) with less memory and energy cost, while not causing
   considerable communication overhead.

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 April 25, 2013.

Copyright Notice

   Copyright (c) 2012 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



Qiu, et al.              Expires April 25, 2013                 [Page 1]


Internet-Draft                    kemp                      October 2012


   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Network Assumptions  . . . . . . . . . . . . . . . . . . . . .  5
   3.  Shared-Key Discovery . . . . . . . . . . . . . . . . . . . . .  6
   4.  Dynamic Authentication and Key Establishment Protocol  . . . .  7
     4.1.  Basic Protocol . . . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Key Management . . . . . . . . . . . . . . . . . . . . . .  8
     4.3.  Distribution Mode  . . . . . . . . . . . . . . . . . . . . 10
     4.4.  Node Bootstraps  . . . . . . . . . . . . . . . . . . . . . 11
     4.5.  Working with Multiple Trust Domains  . . . . . . . . . . . 11
     4.6.  Packet Format in Link Layer  . . . . . . . . . . . . . . . 12
   5.  Security Consideration . . . . . . . . . . . . . . . . . . . . 14
   6.  IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 16
   7.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 18
   Appendix A.  Version History . . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20























Qiu, et al.              Expires April 25, 2013                 [Page 2]


Internet-Draft                    kemp                      October 2012


1.  Introduction

   The demand of wireless sensor networks (WSNs) is growing
   exponentially.  It has turned out that the sensor networks can be
   widely applied in the areas of healthcare, environment monitoring,
   and the military.  One of the surveys on WSNs points out that, in the
   near future, wireless sensor networks will be an integral part of our
   lives, more so than the present-day personal computer [1].

   A sensor node has low capability in terms of power, computation,
   storage and communication.  A wireless sensor network is composed of
   a large number of wireless sensor nodes and multi-hop communication
   is desired in WSNs.  As a result, security in wireless sensor
   networks has six challenges to overcome: (a) the wireless nature of
   communication, (b) resource limitations of sensor nodes, (c) very
   large and dense WSNs, (d) lack of fixed infrastructure, (e) unknown
   network topology prior to deployment, (f) high risk of physical
   attacks on unattended sensors [2][3].

   The capabilities in term of Scalability, Mobility/Dynamicity Network,
   Latency, etc. are also listed in the RFC documents, i.e.  Routing
   Requirements for Urban Low-Power and Lossy Networks (RFC 5548)[6],
   Routing Requirements for Urban Low-Power and Lossy Networks (RFC
   5673)[7], Home Automation Routing Requirements in Low-Power and Lossy
   Networks (RFC 5826)[8], and Building Automation Routing Requirements
   in Low-Power and Lossy Networks (RFC 5867)[9].

   RFC 5548 required local network dynamics SHOULD NOT impact the entire
   network to be reorganized or re-reconfigured; a viable routing
   security approach SHOULD be sufficiently lightweight that it may be
   implemented across all nodes in a U-LLN; the U-LLN MUST deny any node
   that has not been authenticated to the U-LLN and authorized to
   participate to the routing decision process.

   RFC 5673 addressed the handover speed; a compromised field device
   does not destroy the security of the whole network; because nodes are
   usually expected to be capable of routing, the end-node security
   requirements are usually a superset of the router requirements.

   RFC 5826 needed a node MUST authenticate itself to a trusted node
   that is already associated with the LLN before the former can take
   part in self-configuration or self-organization.  A node that has
   already authenticated and associated with the LLN MUST deny, to the
   maximum extent possible, the allocation of resources to any
   unauthenticated peer.  The routing protocol(s) MUST deny service to
   any node that has not clearly established trust with the HC-LLN.

   RFC 5867 listed the possible security keys below: a) a key obtained



Qiu, et al.              Expires April 25, 2013                 [Page 3]


Internet-Draft                    kemp                      October 2012


   from a trust center already operable on the LLN; b) a pre-shared
   static key as defined by the general contractor or its designee; or
   c) a well-known default static key.

   With the aforementioned limitations of the existing solutions in
   mind, we now propose a secure protocol in dynamic WSN, addressing all
   of the following issues:

   o  A moving sensor node needs to change its attached routers (or
      cluster heads) frequently.

   o  A router (or cluster head) needs to ensure a joining node is not a
      malicious sensor.

   o  A moving node needs to establish a secure tunnel with the new
      router (or cluster head).

   o  The energy consumption for establishing the secure tunnel must be
      minimal.

   One of the important novel features of the proposed protocol is that
   the router or cluster head is employed as sub-base-stations to
   execute key establishment.  This way, the total dependency on the
   base station for key establishment can be avoided.  Also, this
   approach reduces the hops between two communicating ends and hence
   results in reduction of the communication cost.

























Qiu, et al.              Expires April 25, 2013                 [Page 4]


Internet-Draft                    kemp                      October 2012


2.  Network Assumptions

   In this document, we consider a scenario in which a sensor node roams
   within a very large and distributed wireless sensor networks (WSN),
   consisting of a large number of sensor nodes and base stations.  It
   is a typical scenario that is widely adopted in hospital environments
   as the patients or doctors equipped with sensors roam across each
   department in the hospital.  A patient who carries the sensor nodes
   can move freely within the range of a hospital.  When a wireless
   sensor node is moving, its routing path and neighborhood keep
   changing.  The moving node needs to be authenticated to the new
   neighbors and to establish a key for secure communication.

   This scenario reflects the problems described in Section 1: (a)
   composition by a large number of sensor nodes; (b) communication
   based on wireless multi-hop mechanism; (c) no fixed infrastructure;
   (d) the possible location change of sensor node (patient).
   Therefore, the challenges of this network assumption are how to
   establish a secure channel with these routers.
































Qiu, et al.              Expires April 25, 2013                 [Page 5]


Internet-Draft                    kemp                      October 2012


3.  Shared-Key Discovery

   In the WSN environment, as data transmission consumes much more
   energy than computation, the probabilistic solution is widely
   accepted in order to reduce the storage and communication overhead
   during key establishment.

   So far in the literature, numerous random key pre-distribution
   schemes have been proposed.  For example, in Chan et al.'s scheme[4],
   each sensor node stores a random set of Np dedicated pair-wise keys
   to achieve the probability p that two nodes share a key.  At the key
   setup phase, each node ID is matched with Np other randomly selected
   node IDs with probability p.  A distinct pair-wise key is generated
   for each ID pair, and is stored in both nodes' key-chain along with
   the ID of the other party.  During the shared-key discovery phase,
   each node broadcasts its ID so that neighboring nodes can tell if
   they share a common pair-wise key.  Note that Chan et al.'s scheme
   reduces the storage overhead by sacrificing key connectivity, but it
   still provides perfect key resilience.

   In this protocol, it is assumed that a sensor node (carried by a
   patient) can move within a special range (e.g. hospital).  As each
   sensor's memory is severely constrained, each sensor may only store a
   small set of keys randomly selected from a key pool at the
   deployment.  Two nodes may use any existing key discovery protocol
   (e.g., the solution proposed in [4]) to find a common key from their
   own sets.  If the common key is not found, the key establishment
   scheme will be initiated.  The reason why binding a general pre-
   shared key discovery phase to the protocol is to reduce the energy
   cost as much as possible.





















Qiu, et al.              Expires April 25, 2013                 [Page 6]


Internet-Draft                    kemp                      October 2012


4.  Dynamic Authentication and Key Establishment Protocol

4.1.  Basic Protocol

   Due to the limited storage of sensor nodes, the pre-shared key-pair
   is not always available between the roaming node and its new
   neighbors in the circumstance of a dynamic node roaming within large
   WSNs (e.g., in hospitals and nuclear power plants).  Therefore it
   requires an efficient and scalable protocol to establish and update
   the keys among nodes for secure communications.

   Figure 1 shows the basic architecture and message flow of our
   protocol for authentication and key establishment in dynamic WSNs.
   When a dynamic sensor node moves to a new area and wants to attach to
   a router or a cluster head in this area, it first sends a request
   message to the base station (refer to Figure 1).

                        +--------+
                        | Router |
                        +--------+
                       /         |\
               notice /            \ appv
                     /              \
                   |/                \
             +--------+           +---------+
             | Sensor |    req    |  Base   |
             |  Node  |---------->| Station |
             +--------+           +---------+

      Figure 1. The basic architecture and message flow of KEMP protocol


   req={Src=SN, Dst= BS, RT||R0||MAC(K_BN, SN||RT||R0)}                    (1)

   where Src and Dst denote the source and destination address of a
   message respectively.  SN, BS and RT are identifiers for sensor node,
   base station and router, respectively.  R0 denotes a random number
   generated by the sensor node.  MAC indicates the message
   authentication code algorithm with a key and K_BN is the shared
   secret key between the base station and the sensor node.

   After receiving the req message, the base station will check its
   revocation list whether the sensor node has been revoked.  If the
   sensor node is acceptable, then the base station verifies the MAC
   message.  If the result is positive, the base station will generate a
   session key K_NR for the roaming sensor node and the router (or
   cluster head).




Qiu, et al.              Expires April 25, 2013                 [Page 7]


Internet-Draft                    kemp                      October 2012


   K_NR = H(K_BN, SN||R0||R1)                                              (2)

   where H is a keyed one-way hash function, and R1 is the random number
   selected by the base station.  The base station then sends an
   approval message appv with the session key to the router:

   appv = {Src=BS, Dst=RT, E(K_BR, SN||R0||R1||K_NR)}                      (3)

   where E is an encryption algorithm, and K_BR is the shared secret key
   between the base station and the router.

   After receiving the appv message, the router decrypts the payload and
   extracts the session key KNR, and then sends a notice to the sensor
   node.

   notice = {Src=RT, Dst=SN, R0||R1|| MAC(K_NR, RT||SN|| R0||R1)}          (4)

   Upon getting the notice message, the sensor node extracts the random
   numbers R0 and R1.  After checking if the received random number R0
   is equal to the original R0, the sensor node recalculates the session
   key K_NR = H(K_BN, SN||R0||R1) and then verifies the MAC value.  If
   the result is positive, the sensor node will use the session key for
   the communication with this router afterwards.  The R0 cannot be
   ignored because the sensor node might send out many request messages
   with various R0 if it cannot receive the notice message in time.
   Hence, the sensor node must know which R0 is used in the notice
   message.

   In practice, the router could be any sensor node that the dynamic
   sensor node wants to connect to.

4.2.  Key Management

   In order to manage the keys, every sensor node maintains a table,
   called "Key Cache".  Table 1 shows the structure of the Key Cache.
















Qiu, et al.              Expires April 25, 2013                 [Page 8]


Internet-Draft                    kemp                      October 2012


                 Table 1. The structure of Key Cache
       +----------------------------------------------+
       |       Key Cache in Sensor Node N             |
       +----------------------------------------------+
       | Correspondence Node ID | Key  | Key Lifetime |
       +----------------------------------------------+
       | BS                     | K_BN | T_BN         |
       | Node_i                 | K_Ni | T_Ni         |
       | ... ...                | ...  | ... ...      |
       | Node_j                 | K_Nj | T_Nj         |
       | PreSharedKey_x         | K_x  | T_x          |
       | ... ...                | ...  | ... ...      |
       | PreSharedKey_y         | K_y  | T_y          |
       +----------------------------------------------+


   When a sensor node, say node N, wants to connect to other sensor
   node, say node R, it executes the following procedure:

   (1)  Checks first if there is an existing key pair between them.

   (2)  Otherwise, processes the subroutine of shared-key discovery to
        find a common key between node N and node R based on those
        "PreSharedKeys" in their key caches.

   (3)  If there is still no common key between them, the sensor node
        allocates an entry in the key cache, and assigns Node ID as
        nodeR, Key Stuff as the random number R0 and Key Lifetime as 0,
        as shown in Table 2.

                Table 2. The initial key entry.
       +---------------------------------------------+
       | Correspondence Node ID | Key | Key Lifetime |
       +---------------------------------------------+
       | Node_R                 | R0  | 0            |
       +---------------------------------------------+

   (4)  Then the sensor node initiates the procedure of key
        establishment described in the above section.  After receiving
        the notice message, and recalculating the session key KNR, the
        sensor node updates the entry's key stuff and key lifetime
        accordingly.

   (5)  When the key lifetime is expired, the dynamic sensor node should
        re-initiate the procedure of key establishment described in the
        above section.





Qiu, et al.              Expires April 25, 2013                 [Page 9]


Internet-Draft                    kemp                      October 2012


   (6)  When the sensor node leaves the range of the connected router,
        the sensor node deletes the related entry from its cache table
        in order to save the storage.  In case there is no space for
        adding a new entry, it may first delete the oldest key which has
        expired or will expire soon.

   The base station also maintains a key table (Table 3) that includes
   the secret keys shared with all of the sensor nodes in the network.

           Table 3. The structure of Key Table in basestation
           +--------------------------------+
           |    Key Table in Base Station   |
           +--------------------------------+
           | Node ID | Key   | Key Lifetime |
           +--------------------------------+
           | Node_i  | K_Bi  | T_Bi         |
           | ... ... | ...   | ... ...      |
           | Node_j  | K_Bj  | T_Bj         |
           +--------------------------------+


   If a node is compromised and revoked, its field of key lifetime would
   be marked as negative.

4.3.  Distribution Mode

   In WSNs, the more hops between two communicating ends exist, the
   poorer the traffic performance becomes and the more energy
   consumption is required.  To overcome these problems, we introduce
   the distribution mode.

   The major idea of distribution mode is to deploy the cluster heads as
   the sub-base-stations because a cluster head is more powerful than
   normal sensor nodes.  The distribution mode includes the following
   steps:

   (1)  Each cluster head manages to establish the shared key with its
        neighboring cluster heads after deployment.  There are several
        ways to do this.  One could embed those keys in advance if the
        topology is known at deployment, or use the basic protocol
        described in the above sections, via the base station.  (As this
        is a one-time operation, the overheads may be acceptable.)

   (2)  Each sensor node keeps two base station identifiers (IDs): one
        is a real base station ID; the other is a sub-base-station (the
        cluster head) ID.  Initially, the ID of sub-base-station is a
        real base station.




Qiu, et al.              Expires April 25, 2013                [Page 10]


Internet-Draft                    kemp                      October 2012


   (3)  After deployment, the first round for a mobile node to establish
        the shared key with the nearest cluster head uses the basic
        protocol, too.

   (4)  When the mobile node moves, use the basic protocol to establish
        the shared key with the new cluster head, via the sub-base-
        station (old cluster head) rather than the real base station.

   (5)  After successfully establishing the keys, the sensor node
        updates the ID of sub-base-station with the current cluster
        head.

   (6)  For security reasons, each sensor node must reset its sub-base-
        station ID to the real base station at a specified interval (say
        a few hours or days, depending on the various applications) and
        re-establish keys with its near cluster heads via the real base
        station.  If the base station does not receive any request from
        a sensor node, it considers the sensor node has been
        compromised.

   The distribution mode could provide an efficient and low energy-cost
   solution for the shared-key establishment.  The basic protocol can
   provide the stronger protection since it can immediately block and
   revoke compromised nodes.

4.4.  Node Bootstraps

   The description in this paragraph is how to establish the secure
   session between sensor node SN and its first router RT_first when the
   node wake up in a new sensor networks.

   (1)  After bootstrapping, the sensor node SN sends its first request
        to Base Station BS via RT_first itself (in generic, via the
        reviopuse router RT_previous) as below:

   req={Src=SN, Dst= BS, RT_first||R0||MAC(K_BN, SN||RT_first||R0)}        (5)

   (2)  Hence, the BS will return appv message to RT_first.  Upon
        receiving the notice from RT_first, the sensor node SN could
        establish the secure session with RT_first by normal processing
        descibed in previous sections 4.1 and 4.2

4.5.  Working with Multiple Trust Domains

   This paragraph describes the operation in scenarios of Multiple Trust
   Domains.





Qiu, et al.              Expires April 25, 2013                [Page 11]


Internet-Draft                    kemp                      October 2012


   (1)  If these multiple domains are managed by one base station (key
        centre), each node address should include the prefix of the
        domain.  With the prefix, a base station / key centre could
        distinguish each node and avoid any confliction.

   (2)  If these multiple domains have their own base station, extend
        the node's cache table to store the pre-shared secrets between
        the node and these base stations.

   (3)  If the sensor node cannot decide which base station is its
        destination, let the req message carry a set of all of MACs with
        generated by the secret between the node and the basestation,
        respectively.

4.6.  Packet Format in Link Layer

   The following attributes could be found from the KEMP protocol that
   fits the features of Link Layer :

   (1)  No handshaking between sending and receiving nodes.

   (2)  Receiving node doesn't send an acknowledgement to sending node
        directly.  The acknowledgement will be sent to the sending node
        via the third party.

   Therefore the protocol is suggested to deploy on the Link Layer in
   order to reduce the communication cost and increase communication
   speed.

   The messages in the KEMP protocols are carried in the MAC Command
   Frame / Key Management Protocols (KMP) described in IEEE 802.15.4 and
   IEEE 802.15.9.

        Table 4. 15.4 MAC and IE formats
    +------------------------------------------------------------------+-
    |  Octets:2    |  1  |     0/2    |   0/2/8  |    0/2    |  0/2/8  |
    +--------------+-----+------------+----------+-----------+---------+-
    |Frame control |Seq# |Dest PAN ID |Dest addr |Src PAN ID |Src addr |
    +------------------------------------------------------------------+-

    --------------------------------------------------------------+
      1       |           Variable              |         2       |
    --------------------------------------------+-----------------+
    Auxiliary |       Information Elements      | Frame check seq#|
    Security  +---------------------------------+                 |
    Header    | KMP type | KMP payload fragment |                 |
    --------------------------------------------------------------+




Qiu, et al.              Expires April 25, 2013                [Page 12]


Internet-Draft                    kemp                      October 2012


   A new KMP type ID for KEMP protocol is required.  Currently, the KMP
   type includes:

   (1)  802.1X

   (2)  HIP

   (3)  IKEv2

   (4)  PANA

   (5)  SAE







































Qiu, et al.              Expires April 25, 2013                [Page 13]


Internet-Draft                    kemp                      October 2012


5.  Security Consideration

   In this proposed protocol, the session key K_NR between the sensor
   node and the router is generated by the base station and sensor node
   respectively, and the session key is directly sent to the router from
   the base station by an encrypted packet.  Hence, the session key K_NR
   is never disclosed during transmission.  The session key K_NR is only
   known by the related peers, i.e., the sensor node, the base station
   and the router.

   Referring to equation (2), the session key K_NR is generated by a
   keyed hash function with the shared key K_BN between sensor node and
   base station as well as two random numbers, R0 and R1, which are
   generated by the sensor node and base station respectively.  As both
   R0 and R1 are used only one time, there are not the same session keys
   K_NR.  This property is useful to against the replication attacks.

   Since the session key K_NR is generated by a keyed hash function with
   the secret key K_BN between the sensor node and the base station, the
   different sensor nodes will have different session keys.  This
   feature is useful to protect sensor node privacy.

   Even though an eavesdropper at the edge of the sensor node can
   monitor and capture the random numbers R0 and R1 as well as the
   identity of the sensor node, it is still not able to regenerate the
   session key K_NR due to lack of the secret key K_BN.  Without a
   proper session key, the routers will not forward the packets to next
   nodes.  This attribute could prevent camouflage and traffic attacks.

   Due to the fact that no trusted connection is established between
   sensor node and new router before the connection between them, the
   proposed protocol employs a random number R1 issued by the base
   station.  The sensor node needs to recalculate the K_NR first based
   on the R1 together with K_BN and R0.  Then using the calculated
   session key K_NR to verify the received session key K_NR and the
   random number R1.  If the result is positive, then the sensor node
   will trust that the router is authorized by the base station.

   Besides the function of informing the sensor node that the new
   session key K_NR is ready to use in the router, the notice message
   also plays an important role to check if the sensor node!_s address
   is reachable.  Without this reachability check, the sensor node may
   claim that it is at any location rather than its real location.  It
   could launch redirecting attacks.

   The path between the base station and the router is secure because
   the packet between them is encrypted with a pre-shared key K_BR.




Qiu, et al.              Expires April 25, 2013                [Page 14]


Internet-Draft                    kemp                      October 2012


   The messages from the sensor node to the base station and from the
   router to the sensor node are authenticated by a keyed hash function.
   Before accepting the inward message and making further processing,
   the receivers must verify the authentication.  Since the cost of a
   hash algorithm is very small, the base station and sensor node could
   avoid the attacks of denial of service.

   In order to achieve high efficiency and low energy cost, the protocol
   deploys a distribution mode which uses the cluster headers as the
   sub-base-stations.  Due to the capability of cluster header, it is
   not able to recognize any compromised sensor nodes in time; the
   protocol requires each sensor node to reset its sub-base-station ID
   to the real base station regularly, and to re-establish keys with its
   near cluster heads via the real base station.  This step is also
   useful to avoid a sensor node binding a compromised cluster head for
   long time.

   According to the above analysis, this proposed protocol, which is
   simple and easy to implement, can provide relatively strong
   protection for sensor node networks.

   The solutions based on public keys are not suitable in sensor
   networks.  As sensor nodes are very easy to be compromised and lost,
   the public-key revocation is a very hard work in low power and lossy
   networks due to the 2 reasons below:

   (1)  How and how often to update the revocation list?

   (2)  How to store the revocation list in sensor node?

   Moreover, before deploy the negoation of public keys, the new
   attached node must be ensured it is reachable in the sensor networks.
   Our proposal lets the previous router and basestation to endorse the
   new attaching node.

















Qiu, et al.              Expires April 25, 2013                [Page 15]


Internet-Draft                    kemp                      October 2012


6.  IANA Consideration

   Apply an new IANA number for the KEMP protocol under KMP type.
















































Qiu, et al.              Expires April 25, 2013                [Page 16]


Internet-Draft                    kemp                      October 2012


7.  Conclusions

   In this document, we have proposed an efficient and scalable protocol
   to establish and update the authentication key between any pair of
   sensor nodes in a dynamic wireless sensor network.  Our protocol has
   the following features:

   o  It is suitable for both static and dynamic WSNs.  Any pair of
      nodes can establish a key for secure communication.

   o  A roaming node only deals with its closest router for security.
      There is no need to change the rest of routing path to the base
      station.

   o  The base station can manage a revocation list for lost or
      compromised roaming nodes.

   o  The system is scalable and resilient against node compromise.

   o  The protocol is efficient due to the small number and size of
      signalling messages.

   o  The size of each signalling message is smaller than the IEEE
      802.15.4 frame size so that it can to avoid packet fragmentation
      and the overhead for reassembly.

   o  The distribution mode can considerably reduce the latency.

   o  Any pair of nodes can establish a key.  The protocol guarantees
      that two sensor nodes share at least one key with probability 1
      (100%).

   Thanks to above features, the protocol can satisfy the requirements
   for IPv6 over Low power WPAN Routing [5] and could be the security
   solution deployed in Routing Requirements for Urban Low-Power and
   Lossy Networks (RFC 5548)[6], Routing Requirements for Urban Low-
   Power and Lossy Networks (RFC 5673)[7], Home Automation Routing
   Requirements in Low-Power and Lossy Networks (RFC 5826)[8], and
   Building Automation Routing Requirements in Low-Power and Lossy
   Networks (RFC 5867)[9].

   After comparing with some of the popular and latest protocols used in
   WSNs, our protocol could save about 30% in communication energy, and
   has the higher probability (100%) of sharing a key between two sensor
   nodes with less memory cost than those pre-distribution schemes,
   without incurring in a considerable amount of communication.





Qiu, et al.              Expires April 25, 2013                [Page 17]


Internet-Draft                    kemp                      October 2012


8.  Normative References

   [1]   Akyildiz, I., Sankarasubramaniam, Y., and E. Cayirci, "Wireless
         sensor networks: a survey", Comput. Netw 38, 393-422, 2002.

   [2]   Camtepe, S. and B. Yener,, "Key Distribution Mechanisms for
         Wireless Sensor Networks: a Survey", Technical Report TR-05-07;
         Department of Computer Science, Rensselaer Polytechnic
         Institute: Troy, NY, USA , Mar. 2005.

   [3]   Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over
         Low-Power Wireless Personal Area Networks (6LoWPANs): Overview,
         Assumptions, Problem Statement, and Goals", RFC 4919,
         August 2007.

   [4]   Chan, H., Perrig, A., and D. Song, "Random key predistribution
         schemes for sensor networks", IEEE Symposium on Research in
         Security and Privacy Oakland, California, USA, May 2003.

   [5]   Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
         Statement and Requirements for 6LoWPAN Routing", Work
         in Progress, Aug. 2010.

   [6]   Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing
         Requirements for Urban Low-Power and Lossy Networks", RFC 5548,
         May 2009.

   [7]   Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial
         Routing Requirements in Low-Power and Lossy Networks",
         RFC 5673, October 2009.

   [8]   Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing
         Requirements in Low-Power and Lossy Networks", RFC 5826,
         April 2010.

   [9]   Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, "Building
         Automation Routing Requirements in Low-Power and Lossy
         Networks", RFC 5867, June 2010.

   [10]  "IEEE Standard for Part 15.4: Wireless Medium Access Control
         Layer (MAC) and Physical Layer (PHY) specifications for Low
         Rate Wireless Personal Area Networks (LR-WPANs), IEEE Std
         802.15.4-2006".

   [11]  Moskowitz, J., "Key Management Support for 15.4 and 15.7", IEEE
         P802.15 Working Group for Wireless Personal Area Networks
         (WPANs) KMP Transport Proposal, March 2012.




Qiu, et al.              Expires April 25, 2013                [Page 18]


Internet-Draft                    kemp                      October 2012


Appendix A.  Version History

   o  v00 to v01

      *  Add a new section about the processing of node bootstraps.

      *  Add a new section about the multiple trust domains.

      *  The modification is based on the feedback from Rene Struik,
         Steve Childress, Shoichi Sakane, Greg Zaverucha, Matthew
         Campagna.

   o  v01 to v02

      *  Add a new section about Frame Format.

      *  Apply an IANA number for KEMP protocol under KMP type.


































Qiu, et al.              Expires April 25, 2013                [Page 19]


Internet-Draft                    kemp                      October 2012


Authors' Addresses

   Ying Qiu
   Institute for Infocomm Research, Singapore
   1 Fusionopolis Way
   #21-01 Connexis (South Tower)
   Singapore  138632

   Phone: +65-6408 2053
   Email: qiuying@i2r.a-star.edu.sg


   Jianying Zhou
   Institute for Infocomm Research, Singapore
   1 Fusionopolis Way
   #21-01 Connexis (South Tower)
   Singapore  138632

   Phone: +65-6408 2075
   Email: jyzhou@i2r.a-star.edu.sg


   Feng Bao
   Institute for Infocomm Research, Singapore
   1 Fusionopolis Way
   #21-01 Connexis (South Tower)
   Singapore  138632

   Phone: +65-6408 2073
   Email: baofeng@i2r.a-star.edu.sg





















Qiu, et al.              Expires April 25, 2013                [Page 20]