Subject: Re: [Roll] slot for New Version of draft-qiu-roll-kemp-02.txt

From: QIU Ying <[email-masked]>
Date: Tue, 23 Oct 2012 12:06:49 +0800

Dear JV,

Might I ask a 5-10min slot to update the draft?

Sorry for late applying as I were not sure if I am able to attend IETF85.
 
Regards and Thanks
Qiu Ying

> -----Original Message-----
> From: QIU Ying [mailto:[email-masked]]
> Sent: Tuesday, October 23, 2012 11:57 AM
> To: [email-masked]'; [email-masked]'
> 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."

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 23 Oct 2012 15:23:23 -0500

Hi Jean-Pierre, all,

There is some overlap with this draft and our work on Secure
Bootstrapping that was being pursued until recently in Core WG.

It is still not clear to me which WG should be home for this activity,
can you please clarify?

Regards,

Behcet

On Mon, Oct 22, 2012 at 11:06 PM, QIU Ying <[email-masked]> wrote:
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Oct 2012 11:01:10 -0400

Behcet Sarikaya <[email-masked]> wrote:
    BS> There is some overlap with this draft and our work on Secure
    BS> Bootstrapping that was being pursued until recently in Core WG.

    BS> It is still not clear to me which WG should be home for this activity,
    BS> can you please clarify?

I thought that this was the point of SOLACE.

-- 
Michael Richardson
-on the road-

---

From: QIU Ying <[email-masked]>
Date: Tue, 30 Oct 2012 00:49:09 +0800

Hi, Behcet

Initially, I was also confusing which WG is best for this kind solution. The
draft finally settled down in the ROLL WG because, at that time, there were
many RFCs in ROLL WG about the requirements for LL networks and the KEMP
draft is designed to provide a security solution to meet the requirements
mentioned in these RFCs.

Regards
Qiu Ying

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Michael Richardson
> Sent: Thursday, October 25, 2012 11:01 PM
> To: [email-masked]
> Cc: [email-masked]; Keoh, Sye Loong; [email-masked]
> Subject: Re: [Roll] [6lowpan] slot for New Version of draft-qiu-roll-
> kemp-02.txt
> 
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 29 Oct 2012 17:56:26 +0100

On Oct 29, 2012, at 17:49, QIU Ying <[email-masked]> wrote:

> which WG is best

I think right now we don't know that.
All WGs in the CN/N cluster have the problem and have some unfulfilled charter item in this space.
So we can continue to play tourists and use the WG that happens to have the largest amount of space on the agenda...

In SOLACE, we are discussing right now when to meet during the Atlanta IETF.
It looks like we will meet on Sunday before the reception for some brainstorming and maybe on Monday during lunchtime for getting organized.
If you are interested, please join the SOLACE mailing list:

https://www.ietf.org/mailman/admin/solace

Grüße, Carsten

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Oct 2012 17:31:23 +0000

Carsten, all,

> In SOLACE, we are discussing right now when to meet during the Atlanta IETF.

Would it be timely to spend 10 minutes on this during the saag
session?

I'd really like that the security area not end up being surprised
by whatever is eventually decided so getting a presentation at
saag would be useful at the point where you more or less know
the direction, but are still flexible enough to deal with someone
who e.g. points out significant security issues.

It might be that waiting another meeting cycle or two would be
better if the basic ideas aren't yet firmed up.

So, is this work far enough advanced already for that to be
productive now or is it still so early it'd be counter-productive?
(And presenting at saag before you're ready could very well
be counter-productive - it can be a tough audience;-)

Ta,
S.

> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
> 
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 29 Oct 2012 18:47:24 +0100

> Would it be timely to spend 10 minutes on this during the saag

Splendid idea!
By Thursday, we should have a somewhat clearer idea of what we want to do.

> be counter-productive - it can be a tough audience;-)

Oh, there will be no technical presentation at this point.
These 10 minutes would be about alerting the security community about this activity.
(See my ROLL slides from Vancouver -- http://www.ietf.org/proceedings/84/slides/slides-84-roll-11.pdf)

What we want to do first is 
a) collecting more fleshed out approaches, documenting how precisely they work, and
b) identifying gaps in the existing standards, if any.

If we are successful in getting structure into this, then there might be
1) "system standards" that explain how to tie things together, as well as 
2) potentially point activities addressing these gaps (but these will not be "SOLACE").

Grüße, Carsten

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Oct 2012 20:45:59 +0000

Hiya,

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.

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.

Cheers,
S.

On 10/29/2012 08:32 PM, Michael Richardson wrote:
> 
>>>>>> "Stephen" == Stephen Farrell <[email-masked]> writes:
>     Stephen> Would it be timely to spend 10 minutes on this during the saag
>     Stephen> session?
> 
> 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:
> 
> http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/CullenJennings.pdf
> http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/slides/Cullen1.pdf
> 
>     Stephen> I'd really like that the security area not end up being surprised
>     Stephen> by whatever is eventually decided so getting a presentation at
>     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 someone
>     Stephen> who e.g. points out significant security issues.
> 
> Except that:
> 1) the constrained devices are more constrained than the IP phones
>    described.
> 
> 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"
> 
> 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.
> 
> 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.
> 
>     Stephen> It might be that waiting another meeting cycle or two would be
>     Stephen> better if the basic ideas aren't yet firmed up.
> 
> One meeting cycle won't help.  Four might.
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 29 Oct 2012 22:15:37 +0100

On Oct 29, 2012, at 21:45, Stephen Farrell <[email-masked]> wrote:

> If he and Cullen want to arm-wrestle
> that's fine:-)

Well, Cullen's I-D (please have a look at draft-jennings-core-transitive-trust-enrollment-01.txt,.pdf)
is a very good example for the kind of input document that we are looking for.

But it is just one way of doing things.  There are so many others.  To a large extent, the differences are not just based on technological choices, but on what people are actually trying to do with the smart objects, i.e., what purpose in life they have.

After half a decade of kicking around half-baked solutions in this space in various IETF working groups, I think it is a good idea to spend more time understanding the design space.  How, and where, to spend this time in the most productive way is what I would like to discuss with interested people before we do the SAAG slot: -> [email-masked]

Grüße, Carsten

PS. Here is section 3.3 of the CoRE roadmap I-D, which lists a couple more related drafts:

   Several individual drafts analyze the issues around the security of
   constrained devices in constrained networks.

  | draft-garcia-core-security                      |     | 2012-03-26 |
  | draft-sarikaya-core-sbootstrapping              | -05 | 2012-07-10 |
  | draft-jennings-core-transitive-trust-enrollment | -01 | 2012-10-13 |

   [I-D.garcia-core-security] in particular describes the "Thing
   Lifecycle" and discusses resulting architectural considerations.
   [I-D.jennings-core-transitive-trust-enrollment] demonstrates a
   specific approach to securing the Thing Lifecycle based on defined
   roles of security players, including a Manufacturer, an Introducer,
   and a Transfer Agent.

   Further work around Thing Lifecycles is also expected to occur in the
   SOLACE initiative (Smart Object Lifecycle Architecture for
   Constrained Environments), with its early mailing list at
   [email-masked] -- developed after the model of the COMAN initiative
   (Management for Constrained Management Networks and Devices,
   [email-masked], [I-D.ersue-constrained-mgmt]).