Subject: Re: [6tisch] #32 (terminology): New terms for security

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 5 Dec 2014 23:52:58 +0000

Dear all:

This issue is created to update the terminology draft to:
-  add support the new security text to come in the architecture and 
- prepare for eventually including security items in out upcoming rechartering 

Please consider the proposed text and provide feedback

> 
>     JCE                 the Join Coordination Entity.  This acronym is
>                         chosen to parallel the PCE.
> 
>     joining node        The newly unboxed constrained node that needs to
>                         join a network.
> 
>     join protocol       the protocol which secures initial communication
>                         between the joining node and the JCE
> 
>     join assistant      A constrained node near the joining node that
>                         will act as it's first 6LR, and will relay
>                         traffic to/from the joining node.
> 
>     unique join key     a key shared between a newly joining node, and
>                         the JCE.  This key supports smaller installations
>                         for which asymmetric methods are considered too
>                         large
> 
>     production network  A 802.15.4e network whose encryption/
>                         authentication keys are determined by some
>                         algorithm/protocol.  There may have network-wide
>                         group keys, or per-link keys.
> 
>     production network key  A L2-key known by all authorized nodes, used
>                         for multicast messages
> 
>     per-peer L2 key     a key that results from an exchange (such as MLE)
>                         that creates a pair-wise L2 key which is known
>                         only to the two nodes involved,
>                         [I-D.piro-6tisch-security-issues] calls this a
>                         LinkKey
> 
>     The following terms are used in this document and come from other
>     documents:
> 
>     DevID               [IEEE.802.1AR] defines the secure DEVice
>                         IDentifier as a device identifier that is
>                         cryptographically bound to the device and is
>                         composed of the Secure Device Identifier Secret
>                         and the Secure Device Identifier Credential.
> 
>     IDevID              The Initial secure DEVice IDentifier (IDevID) is
>                         the Device Identifier which was installed on the
>                         device by the manufacturer.
> 
>     LDevID              A Locally significant secure DEVice IDentifiers
>                         (LDevIDs) is a Secure Device Identifier
>                         credential that is unique in the local
>                         administrative domain in which the device is
>                         used.  The LDevID is usually a new certificate
>                         provisioned by some local means, such as the 6top
>                         mechanism defined in this document.
> 
>     CoAP                The CoAP protocol, defined in [RFC7252] is an
>                         HTTP-like resource access protocol.  CoAP runs
>                         over UDP.
> 
>     DTLS                The datagram version of TLS, defined in
>                         [RFC6347], and which can be used to secure CoAP
>                         in the same way that TLS secures HTTP.
> 
>     ARO                 [RFC6775]defines a number of new Neighbor
>                         Discovery options including the Address
>                         Registration Option
> 
>     DAR/DAC             [RFC6775]defines the Duplicate Address Request
>                         and Duplicate Address Confirmation options to
>                         turn the multicasted Duplicate Address Detection
>                         protocol into a client/server process
> 
>     EARO                [I-D.thubert-6lo-rfc6775-update-reqs]extends the
>                         ARO option to include some additional fields
>                         necessary to distinguish duplicate addresses from
>                         nodes that have moved networks when there are
>                         mulitple LLNs linked over a backbone.
> 
> --
> -------------------------------------------------+----------------------
> -------------------------------------------------+---
>  Reporter:  Michael Richardson                   |      Owner:
>   <[email-masked]>                        |  [email-masked]
>      Type:  defect                               |     Status:  new
>  Priority:  major                                |  Milestone:
> Component:  terminology                          |    Version:
>  Severity:  Active WG Document                   |   Keywords:
> -------------------------------------------------+----------------------
> -------------------------------------------------+---
> 
> Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/32>
> 6tisch <http://tools.ietf.org/6tisch/>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 6 Dec 2014 00:22:22 +0000

My own revue:

Cheers
 
> >                         chosen to parallel the PCE.

[PT] I'd remove "This acronym is chosen to parallel the PCE." And say that this is a central entity like the PCE that is in charge of authorization in the network and providing security material to the joining devices.

> >     joining node        The newly unboxed constrained node that needs to

[PT] The joining node (JN) leverages the JA and the JCE to learn or refresh its knowledge of the network operational state, typically the TSCH schedule, and to obtain security material such as keys, so as to participate to the production network.

> >                         traffic to/from the joining node.
[PT] Again, add the acronym

> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 19 Dec 2014 13:56:14 +0100

+1 on Pascal's suggestions.

Maria Rita, are those definitions you would have time to add to the draft?

On Sat, Dec 6, 2014 at 1:22 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:
> [PT] I'd remove "This acronym is chosen to parallel the PCE." And say that
> this is a central entity like the PCE that is in charge of authorization in
> the network and providing security material to the joining devices.
>
> [PT] The joining node (JN) leverages the JA and the JCE to learn or
> refresh its knowledge of the network operational state, typically the TSCH
> schedule, and to obtain security material such as keys, so as to
> participate to the production network.
>
>

---

From: Qin Wang <[email-masked]>
Date: Fri, 19 Dec 2014 14:42:45 +0000 (UTC)

+1
Qin 

     On Friday, December 19, 2014 8:56 PM, Thomas Watteyne <[email-masked]> wrote:

 +1 on Pascal's suggestions.
Maria Rita, are those definitions you would have time to add to the draft?
On Sat, Dec 6, 2014 at 1:22 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:
My own revue:

Cheers

---

From: Rene Struik <[email-masked]>
Date: Fri, 19 Dec 2014 10:10:57 -0500

Hi Thomas:

I think adding these terms right now is somewhat premature (sometimes: 
really premature).

Some comments below.

Rene

On 12/19/2014 7:56 AM, Thomas Watteyne wrote:
> On Sat, Dec 6, 2014 at 1:22 AM, Pascal Thubert (pthubert) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     My own revue:
>
>     Cheers
>
>     [PT] I'd remove "This acronym is chosen to parallel the PCE." And
>     say that this is a central entity like the PCE that is in charge
>     of authorization in the network and providing security material to
>     the joining devices.
>
RS>>
The notion of "newly unboxed" is incorrect: a joining node is just a 
node that would like to be admitted to the network and be able to 
consume bandwidth resources. This could be a device just out of shrink 
wrap, but also a device that moves from one network to the next, does 
join n+1, etc.
<<RS
>
>     [PT] The joining node (JN) leverages the JA and the JCE to learn
>     or refresh its knowledge of the network operational state,
>     typically the TSCH schedule, and to obtain security material such
>     as keys, so as to participate to the production network.
>
RS>> There is no such thing as a production network.
<<RS
>     > >                         between the joining node and the JCE
RS>> The join protocol is more refined than this, since includes three 
stages (authentication, authorization, and configuration steps). See 
also draft-struik-6tisch-security-architecture-elements-00.
<<RS
>     > >                         traffic to/from the joining node.
RS>>
There is no conclusion yet as to whether the join assistant is simply a 
relay or not. This is still being discussed at the 6tisch security calls 
(came up during the call of last Tue, Dec 16, 2014, 5pm EST).
<<RS
>     > >                         for which asymmetric methods are
RS>>
This would conflict need to support heterogeneous deployment. Again, 
never discussed on security calls to have this mode. This may needlessly 
complicate the design, except when evidence to the contrary is provided.
<<RS
>     > >                         group keys, or per-link keys.
RS>>
This definition is meaningless.
<<RS
>     > >     production network key  A L2-key known by all authorized
RS>>
This seems to refer to a network-wide key, as 802.15.4 defines with 
KeyIdMode unequal to 0x00. However, term is very imprecise.
<<RS
>     > >  [I-D.piro-6tisch-security-issues] calls this a
RS>>
The term link key is defined in 802.15.4-2006 onwards. No need for new 
definitions.
<<RS
>     > >                         and the Secure Device Identifier
RS>>
Completely premature to bake in 802.1ar certs.
<<RS
>     > >                         device by the manufacturer.
RS>>
Completely premature again. Besides, model promotes lock-in and very 
negative press. Issue has not been addressed so far.
<<RS
>     > >                         mechanism defined in this document.
RS>>
Again, completely premature to drop something in that has not been 
ironed out.
<<RS
>     > >   <[email-masked] <mailto:[email-masked]>>    
>                       | [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 19 Dec 2014 10:53:57 -0500

> [PT] I'd remove "This acronym is chosen to parallel the PCE." And say
    > that this is a central entity like the PCE that is in charge of
    > authorization in the network and providing security material to the
    > joining devices.

I don't object to removing that sentence.

JCE - The Join Coordination Entity.  This is a role. The JCE is a central
    entity like the Path Computation Engine (PCE), that is in charge of
    authorization to join a network. The JCE provides security credentials
    to joining devices.

    > refresh its knowledge of the network operational state, typically the
    > TSCH schedule, and to obtain security material such as keys, so as to

good.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Pat Kinney <[email-masked]>
Date: Fri, 19 Dec 2014 11:22:13 -0600

I agree with a number of Rene’s issues:

- joining node			The newly unboxed constrained node that needs to join a network

I think “unboxed” isn’t the correct term, but I have questions as to what was intended a) device that has never been a node within the desired network or b) device that is not currently a node in the desired network?  Selection of a) or b) would lead us to the correct term.

- production network	A 802.15.4e network whose encryption/authentication keys are determined by some algorithm/protocol.  There may have network-wide group keys, or per-link keys

I believe that the terminology "production network” was intended to identify the permanent (non-ephemeral) operational network that is performing a desired function. Since production has a somewhat narrow meaning, perhaps using a term like “purposed” might be better.

Pat

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
[email-masked] <mailto:[email-masked]>

On 19, Dec2014, at 9:10, Rene Struik <[email-masked]> wrote:

Hi Thomas:

I think adding these terms right now is somewhat premature (sometimes: really premature).

Some comments below.

Rene

On 12/19/2014 7:56 AM, Thomas Watteyne wrote:
> On Sat, Dec 6, 2014 at 1:22 AM, Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>> wrote:
> My own revue:
> 
> Cheers
> 
RS>>
The notion of "newly unboxed" is incorrect: a joining node is just a node that would like to be admitted to the network and be able to consume bandwidth resources. This could be a device just out of shrink wrap, but also a device that moves from one network to the next, does join n+1, etc.
<<RS
> > >                         between the joining node and the JCE
RS>> The join protocol is more refined than this, since includes three stages (authentication, authorization, and configuration steps). See also draft-struik-6tisch-security-architecture-elements-00.
<<RS
> > >                         traffic to/from the joining node.
RS>>
There is no conclusion yet as to whether the join assistant is simply a relay or not. This is still being discussed at the 6tisch security calls (came up during the call of last Tue, Dec 16, 2014, 5pm EST).
<<RS
> > >                         for which asymmetric methods are considered too
RS>>
This would conflict need to support heterogeneous deployment. Again, never discussed on security calls to have this mode. This may needlessly complicate the design, except when evidence to the contrary is provided.
<<RS
RS>>
> > >     production network key  A L2-key known by all authorized nodes, used
RS>>
This seems to refer to a network-wide key, as 802.15.4 defines with KeyIdMode unequal to 0x00. However, term is very imprecise.
<<RS
> > >                         [I-D.piro-6tisch-security-issues] calls this a
RS>>
The term link key is defined in 802.15.4-2006 onwards. No need for new definitions.
<<RS
RS>>
> > >                         device by the manufacturer.
RS>>
Completely premature again. Besides, model promotes lock-in and very negative press. Issue has not been addressed so far.
<<RS
> > >                         mechanism defined in this document.
RS>>
Again, completely premature to drop something in that has not been ironed out.
<<RS
> > >   <[email-masked] <mailto:[email-masked]>>                        |  [email-masked] <mailto:[email-masked]>
> > > Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/32 <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/32>>
> > > 6tisch <http://tools.ietf.org/6tisch/ <http://tools.ietf.org/6tisch/>>
> >
> > https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
> 
> https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
> 
> 
> https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>

-- 
email: [email-masked] <mailto:[email-masked]> | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
6tisch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Michael Richardson <[email-masked]>
Date: Fri, 19 Dec 2014 13:23:59 -0500

> I think “unboxed” isn’t the correct term, but I have questions as to
    > what was intended a) device that has never been a node within the
    > desired network or b) device that is not currently a node in the
    > desired network?  Selection of a) or b) would lead us to the correct
    > term.

I'm not crazy about "unboxed" either, but... the idea I want to express, is
that the device is in a factory default situation, and that it was not
provisioned in some customer-specific way by the factory.

A node that has previously been on another network would not qualify.
(such a node could possibly be returned to factory default, but there are
issues about theft and resale which matter here).

    > - production network	A 802.15.4e network whose
    > encryption/authentication keys are determined by some
    > algorithm/protocol.  There may have network-wide group keys, or
    > per-link keys

    > I believe that the terminology "production network” was intended to
    > identify the permanent (non-ephemeral) operational network that is
    > performing a desired function. Since production has a somewhat narrow
    > meaning, perhaps using a term like “purposed” might be better.

so one would say "purposed network" ?  I don't object, but I find it awkward.
(And purposed network multicast key...)

---

From: Pat Kinney <[email-masked]>
Date: Fri, 19 Dec 2014 13:45:30 -0600

I agree with Michael's comments, how about using "Operational Network" instead of "Production Network"?
 
Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
[email-masked]

On 19, Dec2014, at 12:23, Michael Richardson <[email-masked]> wrote: