Re: [6lowpan] New Version Notification for draft-qiu-roll-kemp: Do need an alternative security design ?

Rene Struik <> Mon, 29 October 2012 18:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8BBCD21F8702; Mon, 29 Oct 2012 11:27:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K+0dQastVC0S; Mon, 29 Oct 2012 11:27:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5F0AA21F8741; Mon, 29 Oct 2012 11:27:20 -0700 (PDT)
Received: by with SMTP id x24so2498278iak.31 for <multiple recipients>; Mon, 29 Oct 2012 11:27:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=ZP0ZjHkgf2qXokPgKLLVaDLCbP40pLS5VeHiSiZ6jJ8=; b=SvsMxLfHIMPYNTsFbPjzpmP3tHSiCFW214n8WSQyK0Ukvgru7Y88hl82lIHPaelAuf yK5sdzbA2gCdE3qU2R/yrTlcYREhX8Wr9XAtGodypTvUdrwtGBLDbtaIdMUpw6FM8V0f d12zph5zkoc+Fb+Oeolwi2hlc5iYkkZdqzQHxkSLlYSF+IvYRT20oUXSHpADdDtfOSPg DcdvjM4uZgN4wzNJgBeSFSTFjlwKVvRq2a0iWdny3BSHYq1JtY1X9rbx/dw5iVhPXIUI EdGrPCbZKR6X3YEQUgFEzsNab5n5Oor4LoS9TFYxVPQFbtcj2C8LyO1DngYfoR5w/Taw jyTg==
Received: by with SMTP id vr3mr10433261igb.43.1351535239877; Mon, 29 Oct 2012 11:27:19 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id uz1sm6583031igb.16.2012. (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Oct 2012 11:27:19 -0700 (PDT)
Message-ID: <>
Date: Mon, 29 Oct 2012 14:26:48 -0400
From: Rene Struik <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: QIU Ying <>
References: <02a001cdb5ee$e34164d0$a9c42e70$>
In-Reply-To: <02a001cdb5ee$e34164d0$a9c42e70$>
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [6lowpan] New Version Notification for draft-qiu-roll-kemp: Do need an alternative security design ?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Oct 2012 18:27:22 -0000

Hi Qiu:

Just curious: could you elaborate a little bit on the RFC 4225, Section
5.2 remark below? I just would like to understand scalability, resource
utilization, and other issues somewhat better and may have missed
something here. In particular, if one uses a symmetric-key scheme with
online involvement  of a trusted party who distributes pairwise keying
material, doesn't one then get lots of message traffic to/from this
third party and its local neighbors for each protocol instantiation?

On a more general note, agreed there is a need to tackle trust life
cycle management in a dedicated forum. Originally, I thought the Smart
Object Security Workshop (which we had end of March 2012, just prior to
the IETF meeting) would be a good forum to tackle issues, but felt we
missed some opportunities there to bring forward an agenda of things to
accomplish (in my mind, there was too much inside the box thinking in
terms of "tweaks to IETF drafts"), with less emphasis on what makes
ubiquitous networking different from a deployment use case perspective
(e.g., the lighting use case example comes to mind).

Unfortunately, I will not be at the Atlanta meeting, though I might be
in Vancouver. Glad to contribute to call to action there.

Best regards, Rene

On 10/29/2012 12:03 PM, QIU Ying wrote:
> Dear all,
> Do need an alternative security design instead of the current public key protocols in key establishment? It's one of arguments in previous WG meeting.
> My answer is yes. Actually, the similar discussion had been raised in mobile IPv6 WG (RFC4225).
> Besides the authentication, another major check is the reachability checking to verify if the claimed mobile node is reachable (section 4.1). RFC4225 also explains why the current Public Key Infrastructure (i.e. IKE) is not accepted in mobile IPv6 (section 5.2).
> Frankly, the scheme used in KEMP is not fresh new. It is in style of the popular Kerberos. Instead of sending the ticket to visiting server from client directly in Kerberos, the ticket is sent to the visiting server (new nearby router in KEMP) from the KDC (base station in KEMP). The benefit of this modification includes: 1) reduce the communication; 2) the client (mobile node in KEMP) is check if reachable from the 3rd party (new nearby router); 3) revocation in time.
> Thank to many WG participants commenting on the draft (inclusive Rene Struik, Steve Childress, Shoichi Sakane, Greg Zaverucha, Matthew Campagna), the draft should be more mature and stronger.
> Regards
> Qiu Ying
>> -----Original Message-----
>> From: QIU Ying []
>> Sent: Tuesday, October 23, 2012 11:57 AM
>> To: ''; ''
>> Subject: FW: New Version Notification for draft-qiu-roll-kemp-02.txt
>> Hi,
>> The KEMP draft is updated. The messages in the draft will be carried in
>> KMP format proposed by IEEE802.15.9 working group so that the KEMP
>> protocol is compatible with IEEE802.15.9 and could be deployed in layer
>> 2.
>> Regards
>> Qiu Ying
>> -----Original Message-----
>> A new version of I-D, draft-qiu-roll-kemp-02.txt has been successfully
>> submitted by Ying Qiu and posted to the IETF repository.
>> Filename:	 draft-qiu-roll-kemp
>> Revision:	 02
>> Title:		 Lightweight Key Establishment and Management
>> Protocol in Dynamic Sensor Networks (KEMP)
>> Creation date:	 2012-10-22
>> WG ID:		 Individual Submission
>> Number of pages: 20
>> URL:   
>> kemp-02.txt
>> Status:
>> Htmlized:
>> Diff:  
>> 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.
>> The IETF Secretariat
> 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."
> _______________________________________________
> 6lowpan mailing list

email: | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363