From rstruik.ext@gmail.com  Thu Nov  1 06:13:45 2012
Return-Path: <rstruik.ext@gmail.com>
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 8581B21F8E6D; Thu,  1 Nov 2012 06:13:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 Gg9DU11fFrUM; Thu,  1 Nov 2012 06:13:44 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id A9DA521F8E5A; Thu,  1 Nov 2012 06:13:05 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id 9so4055097iec.31 for <multiple recipients>; Thu, 01 Nov 2012 06:13:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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=KVxXbD3bDV5ciVVoHDBP5+GglneZB7yWe2iN0+Uzbh4=; b=cfziMUgKOHi8dDCh1nJ69VvFnbzaEHtJSemvMdZkkz37tH4/PzRQYys/eGR3WNWy9b nhR140yPULIWePlnmDwxYS2Kij58eF7gjfrrHiHDhC+baIkW0wTtjR4kQSb3svbscYEg VVuGxt8fmqSEBDsQTypW7irc+DJsJLMnSbcjCxs+43XTWrZQQukUSP/5eA6KyXGILJBh YRKIqyq3zfVPBIsdq/kg9pSsh9GRzDL60LQzIWhrjOAeWSX8BO7uqe9v6JzI/kQkTV0p dJDXOKLRsXA7SQrl3O4MnzYA8z02IIOqqf2wOuHb6OT0nzslwJ0QC3pIQLuO0O6BCKDN XwoA==
Received: by 10.42.37.142 with SMTP id y14mr34176617icd.44.1351775585274; Thu, 01 Nov 2012 06:13:05 -0700 (PDT)
Received: from [192.168.1.100] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.4.27]) by mx.google.com with ESMTPS id ez8sm5721394igb.17.2012.11.01.06.13.03 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Nov 2012 06:13:04 -0700 (PDT)
Message-ID: <5092753D.1040700@gmail.com>
Date: Thu, 01 Nov 2012 09:12:29 -0400
From: Rene Struik <rstruik.ext@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: QIU Ying <qiuying@i2r.a-star.edu.sg>
References: <02a001cdb5ee$e34164d0$a9c42e70$@a-star.edu.sg> <508ECA68.4030402@gmail.com> <036901cdb788$a481d5e0$ed8581a0$@a-star.edu.sg>
In-Reply-To: <036901cdb788$a481d5e0$ed8581a0$@a-star.edu.sg>
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: roll@ietf.org, 6lowpan@ietf.org
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: Thu, 01 Nov 2012 13:13:45 -0000

Hi Qiu:

Thanks for your note. One quick note re key revocation: key lifecycle
issues are independent of the "color" of the key (i.e., whether the key
is symmetric-key or public-key). Interestingly enough, usually this
issue is conveniently forgotten when symmetric keys come along, while
inflated when the word public key is mentioned. In practice, the main
reason for revocation would usually be an authorization change and not
so much a key compromise setting. If so, revocation can be toned down
in smart object setting, since devices can be expected not to change
affiliation that often. On the other hand, devices are less well
protected, so key compromise may happen (if one does not implement key
security and implementation security with care).

I put a marker in my calendar to revisit your draft in detail. Meanwhile,
have a good discussion at the IETF meeting next week.

Best regards, Rene

On 10/31/2012 12:56 PM, QIU Ying wrote:
> Hi, Rene
>
> Thanks for your comments.
>
> The discussion of using public keys in MIP6 WG was much more than the
> description in RFC 4225, e.g. the lack of global PKI, the key revocation,
> etc. These issues also restricted to accept the public key schemes in MIPv6
> since a mobile device are always roaming and lost easily. 
>
> Regarding the scalability, according to my understanding, for example IKE, a
> pre-configured security policy (SP), which based on the home address of
> mobile devices, is needed before IKE exchange procedure. The
> pre-configuration is lack of scalability as the visiting mobile devices
> could be from any locations or any domains. 
>
> The IKE scheme is only solve the issue of authentication between the mobile
> device and the correspondent node. It cannot ensure that a mobile device is
> reachable from other nodes.
>
> "resource utilization": did you mean the limited capability of mobile
> devices? I cannot remember if there are a lot of words on the capability in
> the MIPv6 specification. I thought it is not practice to involve the
> revocation checking in a mobile device. Anyway, the capability issue is much
> more sensitive in LLNs than in mobile networks.
>
> Your observation is correct that "get lots of message traffic to/from this
> third party and its local neighbours" because need more hops. In KEMP
> protocol, using the base station as the trust third party is only in the
> bootstraps phase (or at a specified interval).  In the following update
> phases, the distribution mode should be employed. In the distribution mode,
> the previous neighbour router is role as the trust 3rd party to introduce
> the moving sensor to the next neighbour router. In this case, the total hops
> could reduce to 3. By the way, in the public key scheme, the extra messages
> / communications are required when the certifications need to update.
>
> I hope that the above explanation could be express the actual concept of the
> MIPv6 authors, not just on my own understanding ;)
>
> Regards
> Qiu Ying
>
>
>> -----Original Message-----
>> From: Rene Struik [mailto:rstruik.ext@gmail.com]
>> Sent: Tuesday, October 30, 2012 2:27 AM
>> To: QIU Ying
>> Cc: roll@ietf.org; 6lowpan@ietf.org
>> Subject: Re: [6lowpan] New Version Notification for draft-qiu-roll-kemp:
>> Do need an alternative security design ?
>>
>> 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 [mailto:qiuying@i2r.a-star.edu.sg]
>>>> Sent: Tuesday, October 23, 2012 11:57 AM
>>>> To: 'roll@ietf.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."
>>> _______________________________________________
>>> 6lowpan mailing list
>>> 6lowpan@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6lowpan
>>
>> --
>> email: rstruik.ext@gmail.com | Skype: rstruik
>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
> 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."


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


From qiuying@i2r.a-star.edu.sg  Thu Nov  1 22:39:11 2012
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 BC60F21F943A; Thu,  1 Nov 2012 22:39:11 -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=[AWL=0.000,  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 YlHKKvXkzPOJ; Thu,  1 Nov 2012 22:39:10 -0700 (PDT)
Received: from gw1.scei.a-star.edu.sg (gw1.scei.a-star.edu.sg [192.122.140.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4D721F947B; Thu,  1 Nov 2012 22:39:08 -0700 (PDT)
Received: from S3-CAS05.shared-svc.local ([10.217.253.201]) by gw1.scei.a-star.edu.sg (8.14.4/8.14.4) with ESMTP id qA25d3Bc001568;  Fri, 2 Nov 2012 13:39:03 +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; Fri, 2 Nov 2012 13:39:02 +0800
From: QIU Ying <qiuying@i2r.a-star.edu.sg>
To: "'Rene Struik'" <rstruik.ext@gmail.com>
References: <02a001cdb5ee$e34164d0$a9c42e70$@a-star.edu.sg> <508ECA68.4030402@gmail.com> <036901cdb788$a481d5e0$ed8581a0$@a-star.edu.sg> <5092753D.1040700@gmail.com>
In-Reply-To: <5092753D.1040700@gmail.com>
Date: Fri, 2 Nov 2012 13:44:50 +0800
Message-ID: <003a01cdb8bd$3b5d1c60$b2175520$@a-star.edu.sg>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac24MqIJUFfwGcaFRPm7g4FzUBBTYgAh6r9g
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-11-02_01:2012-11-01, 2012-11-02, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1211010391
Cc: roll@ietf.org, 6lowpan@ietf.org
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: Fri, 02 Nov 2012 05:39:11 -0000

Hi, Rene

The idea of smart setting to tone down the revocation is very interesting.
As we know, the vocation issue is a big challenge in security. It is
appreciated that you could describe a bit more in detail.

Regards and Thanks
Qiu Ying
 

> -----Original Message-----
> From: Rene Struik [mailto:rstruik.ext@gmail.com]
> Sent: Thursday, November 01, 2012 9:12 PM
> To: QIU Ying
> Cc: roll@ietf.org; 6lowpan@ietf.org
> Subject: Re: [6lowpan] New Version Notification for draft-qiu-roll-kemp:
> Do need an alternative security design ?
> 
> Hi Qiu:
> 
> Thanks for your note. One quick note re key revocation: key lifecycle
> issues are independent of the "color" of the key (i.e., whether the key
> is symmetric-key or public-key). Interestingly enough, usually this
> issue is conveniently forgotten when symmetric keys come along, while
> inflated when the word public key is mentioned. In practice, the main
> reason for revocation would usually be an authorization change and not
> so much a key compromise setting. If so, revocation can be toned down
> in smart object setting, since devices can be expected not to change
> affiliation that often. On the other hand, devices are less well
> protected, so key compromise may happen (if one does not implement key
> security and implementation security with care).
> 
> I put a marker in my calendar to revisit your draft in detail.
> Meanwhile, have a good discussion at the IETF meeting next week.
> 
> Best regards, Rene
> 
> On 10/31/2012 12:56 PM, QIU Ying wrote:
> > Hi, Rene
> >
> > Thanks for your comments.
> >
> > The discussion of using public keys in MIP6 WG was much more than the
> > description in RFC 4225, e.g. the lack of global PKI, the key
> > revocation, etc. These issues also restricted to accept the public
> key
> > schemes in MIPv6 since a mobile device are always roaming and lost
> easily.
> >
> > Regarding the scalability, according to my understanding, for example
> > IKE, a pre-configured security policy (SP), which based on the home
> > address of mobile devices, is needed before IKE exchange procedure.
> > The pre-configuration is lack of scalability as the visiting mobile
> > devices could be from any locations or any domains.
> >
> > The IKE scheme is only solve the issue of authentication between the
> > mobile device and the correspondent node. It cannot ensure that a
> > mobile device is reachable from other nodes.
> >
> > "resource utilization": did you mean the limited capability of mobile
> > devices? I cannot remember if there are a lot of words on the
> > capability in the MIPv6 specification. I thought it is not practice
> to
> > involve the revocation checking in a mobile device. Anyway, the
> > capability issue is much more sensitive in LLNs than in mobile
> networks.
> >
> > Your observation is correct that "get lots of message traffic to/from
> > this third party and its local neighbours" because need more hops. In
> > KEMP protocol, using the base station as the trust third party is
> only
> > in the bootstraps phase (or at a specified interval).  In the
> > following update phases, the distribution mode should be employed. In
> > the distribution mode, the previous neighbour router is role as the
> > trust 3rd party to introduce the moving sensor to the next neighbour
> > router. In this case, the total hops could reduce to 3. By the way,
> in
> > the public key scheme, the extra messages / communications are
> required when the certifications need to update.
> >
> > I hope that the above explanation could be express the actual concept
> > of the
> > MIPv6 authors, not just on my own understanding ;)
> >
> > Regards
> > Qiu Ying
> >
> >
> >> -----Original Message-----
> >> From: Rene Struik [mailto:rstruik.ext@gmail.com]
> >> Sent: Tuesday, October 30, 2012 2:27 AM
> >> To: QIU Ying
> >> Cc: roll@ietf.org; 6lowpan@ietf.org
> >> Subject: Re: [6lowpan] New Version Notification for draft-qiu-roll-
> kemp:
> >> Do need an alternative security design ?
> >>
> >> 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 [mailto:qiuying@i2r.a-star.edu.sg]
> >>>> Sent: Tuesday, October 23, 2012 11:57 AM
> >>>> To: 'roll@ietf.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."
> >>> _______________________________________________
> >>> 6lowpan mailing list
> >>> 6lowpan@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/6lowpan
> >>
> >> --
> >> email: rstruik.ext@gmail.com | Skype: rstruik
> >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
> > 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."
> 
> 
> --
> email: rstruik.ext@gmail.com | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

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."

From rstruik.ext@gmail.com  Fri Nov  2 06:32:34 2012
Return-Path: <rstruik.ext@gmail.com>
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 39DD421F8A7F; Fri,  2 Nov 2012 06:32:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 Kh9PuPey9+VK; Fri,  2 Nov 2012 06:32:33 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id A5D1A21F8921; Fri,  2 Nov 2012 06:32:32 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id 9so5702914iec.31 for <multiple recipients>; Fri, 02 Nov 2012 06:32:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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=nWvoMy+NI/xXjFi0dkmBPvtjkDZNv9OtwWVo7hMPk+Q=; b=xq8E+6qVpCAtTmP0HV+E7eUmK/wbmWWK8EGCBvt53Cqdrn1hVBy7cZGgCVnVeqjCdw 5ca/YvM7CNU6d/tDal288A13vCpEFaDWH7E8XPby1jCrMeSssixkeYte+tVi73SsXtGx 7pHvMJYwYpCuqqslDLX1yWUamoeWbyiC7w1UkQBFCFEXpQ4mfagGIBYywbIcLJssurEg gu7SmUO04zR4VfbFg4rH06V2dRkakPU1Daurcrz65TbOzk2s1/b/sC8JuuITyYKJD5q+ PLt3RMOZGksiJIBP1qotF+jBrj3Bzy6Go10bMu1Vhj5zCnIlQwBvcNbM2onVlUqJFI1W uLNQ==
Received: by 10.50.16.143 with SMTP id g15mr1714252igd.9.1351863151972; Fri, 02 Nov 2012 06:32:31 -0700 (PDT)
Received: from [192.168.1.100] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.4.27]) by mx.google.com with ESMTPS id az4sm1477061igb.2.2012.11.02.06.32.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 06:32:31 -0700 (PDT)
Message-ID: <5093CB4B.7090904@gmail.com>
Date: Fri, 02 Nov 2012 09:31:55 -0400
From: Rene Struik <rstruik.ext@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: QIU Ying <qiuying@i2r.a-star.edu.sg>
References: <02a001cdb5ee$e34164d0$a9c42e70$@a-star.edu.sg> <508ECA68.4030402@gmail.com> <036901cdb788$a481d5e0$ed8581a0$@a-star.edu.sg> <5092753D.1040700@gmail.com> <003a01cdb8bd$3b5d1c60$b2175520$@a-star.edu.sg>
In-Reply-To: <003a01cdb8bd$3b5d1c60$b2175520$@a-star.edu.sg>
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: roll@ietf.org, 6lowpan@ietf.org
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: Fri, 02 Nov 2012 13:32:34 -0000

Hi Qiu:

Perhaps, I was unclear: I did not suggest a "smart setting to tone down revocation". I did suggest that certificate revocation is only necessary in two cases, viz.
1) loss of secrecy and/or authenticity of the corresponding keying material.
2) change to authorization attributes associated with keying material. 
Case #1 occurs when one has a compromised device (extracted keying material via probing, side channel attacks, crappy security design, etc.). With Case #2, one should think of use cases typically quoted, such as employee receiving a public key issued by organization with authorization attributes and validity period of five years, and then discovering that employee left organization prior to certificate expiration set. (In my mind, not aligning lifetime of authorization with lifetime of cert is an example of bad implementation decisions by the organization [or plain laziness] and not necessary any more.)

With smart objects, I do not see those objects being reassigned continuously (a light switch usually assumes its role for its entire life), thus making reason #2 less likely as a trigger for change. Reason #1 could occur though, since objects can be expected low-cost where one cannot necessarily assume a trusted platform on board of the device (although, one could, e.g., wrap keys using a physical unclonable function and only unwrap during use). Handing out short-lived certs to devices, where assigning a new lease of life depends on some routines involving authentication and, e.g., inspection of whether the device's external casing has been damaged could then do the job. Short-lived certificates in a networked environments are perfectly feasible and per-device cost for internet of things environment should be almost zero (subsidies to support CA's lifestyle aside). 

One final note: once again, it is a misconception to only consider revocation issues with public keys. This topic area is independent of the type of key and applies to symmetric-key keying material as well. (In my mind, the security profession has not done such a terrific job here by mostly ignoring the topic in the symmetric-key case and coming up with umpteen schemes in the public-key setting, not much of them being practical.)

I hope this helps.

Best regards, Rene

==
In practice, the main
reason for revocation would usually be an authorization change and not
so much a key compromise setting. If so, revocation can be toned down
in smart object setting, since devices can be expected not to change
affiliation that often. On the other hand, devices are less well
protected, so key compromise may happen (if one does not implement key
security and implementation security with care).


On 11/2/2012 1:44 AM, QIU Ying wrote:
> Hi, Rene
>
> The idea of smart setting to tone down the revocation is very interesting.
> As we know, the vocation issue is a big challenge in security. It is
> appreciated that you could describe a bit more in detail.
>
> Regards and Thanks
> Qiu Ying
>  
>
>> -----Original Message-----
>> From: Rene Struik [mailto:rstruik.ext@gmail.com]
>> Sent: Thursday, November 01, 2012 9:12 PM
>> To: QIU Ying
>> Cc: roll@ietf.org; 6lowpan@ietf.org
>> Subject: Re: [6lowpan] New Version Notification for draft-qiu-roll-kemp:
>> Do need an alternative security design ?
>>
>> Hi Qiu:
>>
>> Thanks for your note. One quick note re key revocation: key lifecycle
>> issues are independent of the "color" of the key (i.e., whether the key
>> is symmetric-key or public-key). Interestingly enough, usually this
>> issue is conveniently forgotten when symmetric keys come along, while
>> inflated when the word public key is mentioned. In practice, the main
>> reason for revocation would usually be an authorization change and not
>> so much a key compromise setting. If so, revocation can be toned down
>> in smart object setting, since devices can be expected not to change
>> affiliation that often. On the other hand, devices are less well
>> protected, so key compromise may happen (if one does not implement key
>> security and implementation security with care).
>>
>> I put a marker in my calendar to revisit your draft in detail.
>> Meanwhile, have a good discussion at the IETF meeting next week.
>>
>> Best regards, Rene
>>
>> On 10/31/2012 12:56 PM, QIU Ying wrote:
>>> Hi, Rene
>>>
>>> Thanks for your comments.
>>>
>>> The discussion of using public keys in MIP6 WG was much more than the
>>> description in RFC 4225, e.g. the lack of global PKI, the key
>>> revocation, etc. These issues also restricted to accept the public
>> key
>>> schemes in MIPv6 since a mobile device are always roaming and lost
>> easily.
>>> Regarding the scalability, according to my understanding, for example
>>> IKE, a pre-configured security policy (SP), which based on the home
>>> address of mobile devices, is needed before IKE exchange procedure.
>>> The pre-configuration is lack of scalability as the visiting mobile
>>> devices could be from any locations or any domains.
>>>
>>> The IKE scheme is only solve the issue of authentication between the
>>> mobile device and the correspondent node. It cannot ensure that a
>>> mobile device is reachable from other nodes.
>>>
>>> "resource utilization": did you mean the limited capability of mobile
>>> devices? I cannot remember if there are a lot of words on the
>>> capability in the MIPv6 specification. I thought it is not practice
>> to
>>> involve the revocation checking in a mobile device. Anyway, the
>>> capability issue is much more sensitive in LLNs than in mobile
>> networks.
>>> Your observation is correct that "get lots of message traffic to/from
>>> this third party and its local neighbours" because need more hops. In
>>> KEMP protocol, using the base station as the trust third party is
>> only
>>> in the bootstraps phase (or at a specified interval).  In the
>>> following update phases, the distribution mode should be employed. In
>>> the distribution mode, the previous neighbour router is role as the
>>> trust 3rd party to introduce the moving sensor to the next neighbour
>>> router. In this case, the total hops could reduce to 3. By the way,
>> in
>>> the public key scheme, the extra messages / communications are
>> required when the certifications need to update.
>>> I hope that the above explanation could be express the actual concept
>>> of the
>>> MIPv6 authors, not just on my own understanding ;)
>>>
>>> Regards
>>> Qiu Ying
>>>
>>>
>>>> -----Original Message-----
>>>> From: Rene Struik [mailto:rstruik.ext@gmail.com]
>>>> Sent: Tuesday, October 30, 2012 2:27 AM
>>>> To: QIU Ying
>>>> Cc: roll@ietf.org; 6lowpan@ietf.org
>>>> Subject: Re: [6lowpan] New Version Notification for draft-qiu-roll-
>> kemp:
>>>> Do need an alternative security design ?
>>>>
>>>> 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 [mailto:qiuying@i2r.a-star.edu.sg]
>>>>>> Sent: Tuesday, October 23, 2012 11:57 AM
>>>>>> To: 'roll@ietf.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."
>>>>> _______________________________________________
>>>>> 6lowpan mailing list
>>>>> 6lowpan@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/6lowpan
>>>> --
>>>> email: rstruik.ext@gmail.com | Skype: rstruik
>>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>>> 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."
>>
>>
>> --
>> email: rstruik.ext@gmail.com | Skype: rstruik
>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
> 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."


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


From fluffy@cisco.com  Sun Nov  4 09:55:52 2012
Return-Path: <fluffy@cisco.com>
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 623F621F8626; Sun,  4 Nov 2012 09:55:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 EFiW7OlRIV1P; Sun,  4 Nov 2012 09:55:51 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 83F2721F8615; Sun,  4 Nov 2012 09:55:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3877; q=dns/txt; s=iport; t=1352051747; x=1353261347; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zx648dV1GzOpShKn+2bM3+/aAeY41xkQ6v7FWY9XXDo=; b=NoZG36LBQv5ZaV3RHwneAQYLTRJQB/Gr9qCius7XHPtpDemmfGOd4ZI4 Q2N2G4p/xJGD6ZEI6tpOECVwmTISG/9ZDX8s2EviC7JkY9GmBRA6sYd9K WPneGSUHxpMjBqBpWy/O2jmV1w79L7xYc3SZXs5+sWnEb+V1ylC0ygJ5z g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAP2qllCtJV2c/2dsb2JhbABEwzmBCIIeAQEBAgEBAQEBDwEnNAsQAgEIEgYKFBAnCxcOAgQBDQUIDAcHh2IGC5kxnwuMAYVbYQOkVIFrgm+CGQ
X-IronPort-AV: E=Sophos;i="4.80,711,1344211200"; d="scan'208";a="138628238"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 04 Nov 2012 17:55:47 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA4HtkgV032526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 4 Nov 2012 17:55:46 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.001; Sun, 4 Nov 2012 11:55:46 -0600
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Michael Richardson <mcr+ietf@sandelman.ca>, "saag@ietf.org" <saag@ietf.org>, Sean Turner <turners@ieca.com>, Carsten Bormann <cabo@tzi.org>
Thread-Topic: [6lowpan] SOLACE things at SAAG
Thread-Index: AQHNurWd8mDoYb2tQUy4Nk+S++c3Zw==
Date: Sun, 4 Nov 2012 17:55:46 +0000
Message-ID: <C5E08FE080ACFD4DAE31E4BDBF944EB1118ADA6E@xmb-aln-x02.cisco.com>
References: <015901cdb0d3$d38cf1f0$7aa6d5d0$@a-star.edu.sg> <CAC8QAccHFddngBnWynnVbSc=hhwbCmXbh9QRo=jcqPxfGYeiHg@mail.gmail.com> <1116.1351177270@sandelman.ca> <02a101cdb5f5$51109a70$f331cf50$@a-star.edu.sg> <A6012D01-F7B0-406F-8585-FFEF4A0E92D9@tzi.org> <508EBD6B.1070606@cs.tcd.ie> <10703.1351542774@obiwan.sandelman.ca> <508EEB07.8080807@cs.tcd.ie>
In-Reply-To: <508EEB07.8080807@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.78.123]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19338.004
x-tm-as-result: No--48.905900-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <81E1CB44A01F564E8B2605302FA46364@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Sun, 04 Nov 2012 11:39:28 -0800
Cc: "roll@ietf.org" <roll@ietf.org>, "Keoh, Sye Loong" <sye.loong.keoh@philips.com>, "6lowpan@ietf.org" <6lowpan@ietf.org>
Subject: Re: [6lowpan] SOLACE things at SAAG
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: Sun, 04 Nov 2012 17:55:52 -0000

I have been doing some work with constrained devices and would be happy to =
talk about the problem in SAAG. I've spend a fair amount of time talking to=
 few folks that I think of as part of the security mafia to try and underst=
and how to describe some of the threats and try and get crisp about the ove=
rall goals - particularly in thinking about how the problem is different th=
an security problems we have already solved.=20

I do have a sketch of a proposed solution which I think helps people unders=
tand the problem but may or may not be the right path to a good solution.  =
If someone from the security community wanted to help me move this from a s=
ketch to a well formed proposal, that would be great but I think the key th=
ing for SAAG right now is the problem.=20

I'm glad to do this with Carsten - he and I are at pretty opposite ends of =
the spectrum on some of this stuff but the union of our views likely covers=
 a very large percentage of the broad communities views on the topic.=20

Cullen



On Oct 29, 2012, at 14:45 , Stephen Farrell <stephen.farrell@cs.tcd.ie> wro=
te:

>=20
> Hiya,
>=20
> So Carsten volunteered to give saag a heads-up on the
> problem this time. If he and Cullen want to arm-wrestle
> that's fine:-) I'm sure either would do a fine job.
>=20
> I didn't mean to say anything about the solace draft
> being good, bad or indifferent. But I figured someone
> is working on this problem somewhere and would like
> to make sure that whatever solution looks like it'll
> be adopted is something that wouldn't cause saag folk
> to have fits.
>=20
> Cheers,
> S.
>=20
> On 10/29/2012 08:32 PM, Michael Richardson wrote:
>>=20
>>>>>>> "Stephen" =3D=3D Stephen Farrell <stephen.farrell@cs.tcd.ie> writes=
:
>>   Stephen> Would it be timely to spend 10 minutes on this during the saa=
g
>>   Stephen> session?
>>=20
>> I think, if you want to talk something SOLACE related which is more
>> concrete than a possible SOLACE IRTF "charter", then maybe have Cullen
>> talk about:
>>=20
>> http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/Cull=
enJennings.pdf
>> http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/slides/Cull=
en1.pdf
>>=20
>>   Stephen> I'd really like that the security area not end up being surpr=
ised
>>   Stephen> by whatever is eventually decided so getting a presentation a=
t
>>   Stephen> saag would be useful at the point where you more or less know
>>   Stephen> the direction, but are still flexible enough to deal with som=
eone
>>   Stephen> who e.g. points out significant security issues.
>>=20
>> Except that:
>> 1) the constrained devices are more constrained than the IP phones
>>  described.
>>=20
>> 2) the constrained devices probably can not be attacked/p0wned until
>>  after they get on the network, and so actually authenticating to the
>>  network is the "application"
>>=20
>> Cullen's slides provide a really good starting explanation.
>> While the details of the ultimate answer are going to be a bit different
>> in small ways,  the basic architecture he presents has been articulated
>> repeatedly by many.
>>=20
>> So, if your aim is to get more security geeks thinking about attacks,
>> and about defenses, in advance of an actual proposed protocol (and
>> SOLACE is an I*R*TF group, recall. A protocol might not be the result
>> anyway), then I suggest giving Cullen a few minutes to talk about his
>> slide 7,8,9.
>>=20
>>   Stephen> It might be that waiting another meeting cycle or two would b=
e
>>   Stephen> better if the basic ideas aren't yet firmed up.
>>=20
>> One meeting cycle won't help.  Four might.
>>=20
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowpan


From soohongp@gmail.com  Fri Nov 16 18:12:36 2012
Return-Path: <soohongp@gmail.com>
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 EF26721F8B39; Fri, 16 Nov 2012 18:12:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.863
X-Spam-Level: 
X-Spam-Status: No, score=-0.863 tagged_above=-999 required=5 tests=[AWL=-2.734, BAYES_05=-1.11, MISSING_SUBJECT=1.762, RCVD_IN_DNSWL_LOW=-1, TVD_SPACE_RATIO=2.219]
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 0QI3z49Loefr; Fri, 16 Nov 2012 18:12:35 -0800 (PST)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0399721F85F9; Fri, 16 Nov 2012 18:12:34 -0800 (PST)
Received: by mail-bk0-f44.google.com with SMTP id w11so1562586bku.31 for <multiple recipients>; Fri, 16 Nov 2012 18:12:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BZzdX/HeTTQI+RLciyI7X1NAOeL/hohco3vfEBCzYVQ=; b=N7i/GzgJI2ux6dKTdEQWvLVCAO6h1qcjAkN0ZRF0p8g9p6hDSYDGKbRpH1uBhz/e1B WleOxi8AAAQPEml/syxiJAjLllW8rbObYvxlZCOHDPAoAxGn+YblL+vEBGq/V3qMihDT +wDaSx1tRR8YaUmOWh+W8rADgjVbNRP/kw8zekjcY6N0EGSqGD19Wg43eiVOKz2c3bH5 AFnqc2kmDl8aZnz+P9fSRKls+GSZuguA2cFWEs2Iu8U35SEtiUznp7MHEsWqN7WLyjby KR3xZDYKDW+nFvkT9LR8YhmEvbpfGao46KPEptnGER2BOM69RP9j94QY4hpxPSXKcX/8 smCw==
MIME-Version: 1.0
Received: by 10.204.6.87 with SMTP id 23mr2711890bky.78.1353118353834; Fri, 16 Nov 2012 18:12:33 -0800 (PST)
Received: by 10.204.60.81 with HTTP; Fri, 16 Nov 2012 18:12:33 -0800 (PST)
Date: Sat, 17 Nov 2012 11:12:33 +0900
Message-ID: <CAHSr+v2cFZZqxLfvTAp5gOjap2xcwkLMnc0XhDbXtsRhzuqSJw@mail.gmail.com>
From: Daniel Park <soohongp@gmail.com>
To: 2hang@naver.com, 6lowpan@ietf.org, adella3@hanafos.com,  apps-discuss-request@ietf.org, brian@innovationslab.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: [6lowpan] (no subject)
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: Sat, 17 Nov 2012 02:12:36 -0000

  http://www.atlantahardwoodandtile.com/wp-content/plugins/akismet/google235.html