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

["Pascal Thubert (pthubert)" <[e-mail]>]

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:
>   <[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/>