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

[Thomas Watteyne <[e-mail]>]

+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
>