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

[Pat Kinney <[e-mail]>]

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
[e-mail] <mailto:[e-mail]>






On 19, Dec2014, at 9:10, Rene Struik <[e-mail]> 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:
> +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) <[e-mail] <mailto:[e-mail]>> wrote:
> My own revue:
> 
> Cheers
> 
> > >     JCE                 the Join Coordination Entity.  This acronym is
> > >                         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
> > >                         join a network.
> 
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
> 
> > >     join protocol       the protocol which secures initial communication
> > >                         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
> > >     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.
> > >
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
> [PT] Again, add the acronym
> 
> > >     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
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
> > >
> > >     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.
RS>>
This definition is meaningless.
<<RS
> > >
> > >     production network key  A L2-key known by all authorized nodes, used
> > >                         for multicast messages
> > >
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
> > >     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
RS>>
The term link key is defined in 802.15.4-2006 onwards. No need for new definitions.
<<RS
> > >
> > >     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.
> > >
RS>>
Completely premature to bake in 802.1ar certs.
<<RS
> > >     IDevID              The Initial secure DEVice IDentifier (IDevID) is
> > >                         the Device Identifier which was installed on the
> > >                         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
> > >
> > >     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.
> > >
RS>>
Again, completely premature to drop something in that has not been ironed out.
<<RS
> > >     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:
> > >   <[e-mail] <mailto:[e-mail]>>                        |  [e-mail] <mailto:[e-mail]>
> > >      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 <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/32>>
> > > 6tisch <http://tools.ietf.org/6tisch/ <http://tools.ietf.org/6tisch/>>
> >
> > _______________________________________________
> > 6tisch mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
> 
> _______________________________________________
> 6tisch mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
> 
> 
> _______________________________________________
> 6tisch mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>


-- 
email: [e-mail] <mailto:[e-mail]> | Skype: rstruik
cell: [phone] | US: [phone]
_______________________________________________
6tisch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6tisch