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

[Qin Wang <[e-mail]>]

+1
Qin 

     On Friday, December 19, 2014 8:56 PM, Thomas Watteyne <[e-mail]> 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]> 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.

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


> >     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.
> >
[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
> >
> >     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:
> >   <[e-mail]>                        |  [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>
> > 6tisch <http://tools.ietf.org/6tisch/>
>
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch

_______________________________________________
6tisch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6tisch


_______________________________________________
6tisch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6tisch