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

[Rene Struik <[e-mail]>]

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:[e-mail]]
>> Sent: Tuesday, October 30, 2012 2:27 AM
>> To: QIU Ying
>> Cc: [e-mail]; [e-mail]
>> 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:[e-mail]]
>>>> Sent: Tuesday, October 23, 2012 11:57 AM
>>>> To: '[e-mail]'; '[e-mail]'
>>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/6lowpan
>>
>> --
>> email: [e-mail] | Skype: rstruik
>> cell: [phone] | US: [phone]
> 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: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]