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

QIU Ying <qiuying@i2r.a-star.edu.sg> Mon, 29 October 2012 15:56 UTC

Return-Path: <qiuying@i2r.a-star.edu.sg>
X-Original-To: 6lowpan@ietfa.amsl.com
Delivered-To: 6lowpan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CDB21F871D; Mon, 29 Oct 2012 08:56:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1m7MtgTZzRoI; Mon, 29 Oct 2012 08:56:49 -0700 (PDT)
Received: from gw3.scei.a-star.edu.sg (gw3.scei.a-star.edu.sg [192.122.140.12]) by ietfa.amsl.com (Postfix) with ESMTP id 03F4021F86CA; Mon, 29 Oct 2012 08:56:48 -0700 (PDT)
Received: from pps.filterd (gw3 [127.0.0.1]) by gw3.scei.a-star.edu.sg (8.14.4/8.14.4) with SMTP id q9TFtsnH013787; Mon, 29 Oct 2012 23:56:44 +0800
Received: from s3-cas05.shared-svc.local ([10.217.253.201]) by gw3.scei.a-star.edu.sg with ESMTP id 189se9g36r-1; Mon, 29 Oct 2012 23:56:44 +0800
Received: from Win7PC (10.217.253.130) by S3-CAS05.shared-svc.local (10.217.253.201) with Microsoft SMTP Server id 14.1.339.1; Mon, 29 Oct 2012 23:56:43 +0800
From: QIU Ying <qiuying@i2r.a-star.edu.sg>
To: <roll@ietf.org>, <6lowpan@ietf.org>
References:
In-Reply-To:
Date: Tue, 30 Oct 2012 00:03:08 +0800
Message-ID: <02a001cdb5ee$e34164d0$a9c42e70$@a-star.edu.sg>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac2wkf59C4jlyJFSRzOqX2NnRKc2WQAPaWDQAUeD8xA=
Content-Language: en-sg
X-Originating-IP: [10.217.253.130]
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-10-29_02:2012-10-29, 2012-10-29, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=9 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1210290156
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [6lowpan] New Version Notification for draft-qiu-roll-kemp: Do need an alternative security design ?
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Oct 2012 15:56:50 -0000

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 [mailto:qiuying@i2r.a-star.edu.sg]
> Sent: Tuesday, October 23, 2012 11:57 AM
> To: 'roll@ietf.org'org'; '6lowpan@ietf.org'
> 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:             http://www.ietf.org/internet-drafts/draft-qiu-roll-
> kemp-02.txt
> Status:          http://datatracker.ietf.org/doc/draft-qiu-roll-kemp
> Htmlized:        http://tools.ietf.org/html/draft-qiu-roll-kemp-02
> Diff:            http://www.ietf.org/rfcdiff?url2=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.
> 
> 
> 
> 
> 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."