Subject: Re: [Roll] FW: New Version Notification for draft-qiu-6lowpan-secure-router-01

From: Shoichi Sakane <[email-masked]>
Date: Tue, 16 Nov 2010 08:53:55 +0900

Carsten, JP, and All,

On 10/27/10 7:22 PM, QIU Ying wrote:
> http://tools.ietf.org/id/draft-qiu-6lowpan-secure-router-01.txt
>
> The title of the draft had been changed to "Lightweight Key Establishment and Management Protocol in Dynamic Sensor Networks (KEMP)" instead of "Lightweight Secure Router Protocol" in order to make the work more clearly. It will be presented at ROLL WG.
>
> Any comments are appreciated.

I talked with Ying Qiu, the author of KEMP.

Here is my understanding after the discussion.  He proposes a
method to create a session key between the mobile node (N) and
the next hop router (R).  This document seems not define the
concrete way to use the session key.  However, this proposal
would be reasonable scheme under a certain environment which is
"a single trust domain" as Rene mentioned, and where B is able
to verify whether a node was compromised.

== Model ==

N moves among a wireless network.  N has to be authenticated
by an immediate neighbor router (R) before sending any
message to another node (e.g. N2).  In the network, there is an
authorization server (B) which authorizes all nodes including
N.  It generates key materials for a session key of both N and R.
When N is moving to around the next router (Rn), N has to send
a request to B through R in order to get a next shared session
key with Rn.

            ____________
           /            \
          /       _______B-----N2
         Rn      /      /
                R      /
             ...      /
           ..        /
          .         /
         N ====== Rm

     ===: verified session
     ---: not concerned of this protocol, it may be secured.
     ...: session to be verified.

== Assumption ==

N shares a pre-shared key with B.  N shares a session key with
the neighbor router (Rm) somehow before N initiates this protocol.
Rm just forwards a request from N to B, and is not always needed
if the request directly rearches at B.
N has to know that the next neighbor router will be R.
It is like a manner of the handover mechanism.
N has to have more than one neighbor rouers at same time.
One is Rm to send REQ, another is R to get NOTICE, which are
explained below.

== What is missing of this proposal ==

- What is the identifier of each node.
- How to provision each identifier into each node.
- How does N know the address of B.
- How to establish the secure session between N and Rm.
- Any message encoding format.
- Any specific message authentication code algorithm, and
   encryption algorithm.

== How to securely share a session key between N and R ==

                                +--------+
                 +------------- |   R    | <------------+
                 |              +--------+              |
        6)NOTICE |                                      | 4)APPV
                 v                                      |
           +--------+  1)REQ    +--------+          +--------+
           |    N   |---------->|   Rm   |--------->|    B   |
           +--------+           +--------+          +--------+

1) N sends a request (REQ) to B through Rm.  Rm just forwards REQ
    to B.  Rm is not always needed if REQ directly reach at B.

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

       SN,RT,BS: identifier of each node
       R0: random number generated by N
       MAC: a message authentication code
       K_BN: a shared key between B and N

2) B verifies the identifier of N (SN), and knows that the request
    is for R (RT).

3) B generates a session key K_NR for N and R.

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

       R1: random number generated by B

    B encrypts the message contained K_NR by K_BR.

4) B sends an approval (APPV) to R.

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

       E: an encryption algorithm

5) R decrypts the payload encrypted by K_BR, and gets
    the identifier of N (SN) and a session key K_NR.

6) R sends a notice (NOTICE) to N.

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

7) N calculates a session key K_NR.

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

    To check the MAC, N verifies NOTICE was from R wchich was
    authorized by B.

---

From: "QIU Ying" <[email-masked]>
Date: Mon, 22 Nov 2010 19:08:42 +0800

Thank Shoichi for clarifying and summarising this protocol.
 
Shoichi pointed out a very important issue how to establish the secure
session between N and Rm when the node bootstraps.

The issue could be solved by using Rm instead of RT in REQ message.

After bootstrapping, the sensor node N sends its first request to Base
station as below: 
     REQ = {Src=SN, Dst= BS, Rm||R0||MAC(K_BN, SN||RT||R0)}
Hence, the BS will return APPV message to Rm. Upon receiving the notice from
Rm, the sensor node could establish the secure session with Rm by normal
processing.

The responses for other issues mentioned in previous email:

- What is the identifier of each node.
A: For simple, the ID could the node's address.

- How to provision each identifier into each node.
A: the IDs of nodes should be assigned (auto/manual) before deployment. I am
not sure if DHCP is suitable for WSN since it requires more cost in term of
communication and computing.  

- How does N know the address of B.
A: N should carry one or more addresses of the trust base stations before
deployment.

- Any message encoding format.
A: to be fed in future version.

- Any specific message authentication code algorithm and encryption
algorithm.
A:  to be fed in future version.

- under a certain environment which is "a single trust domain"  
A: I cannot understand very well why must be "a single trust domain"? In
multiple domain networks, each node address should include the prefix of the
domain. With the prefix, a base station or key centre could distinguish each
node and avoid any confliction. Maybe I missed something.

Regards and Thanks
Qiu Ying

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Shoichi Sakane
> Sent: Tuesday, November 16, 2010 7:54 AM
> To: [email-masked]
> Subject: Re: [Roll] FW: New Version Notification for draft-qiu-6lowpan-
> secure-router-01
> 
> Carsten, JP, and All,
> 
> > The title of the draft had been changed to "Lightweight Key
> Establishment and Management Protocol in Dynamic Sensor Networks (KEMP)"
> instead of "Lightweight Secure Router Protocol" in order to make the work
> more clearly. It will be presented at ROLL WG.
> 
> >
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

Institute for Infocomm Research disclaimer:  "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you."