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

[Rene Struik <[e-mail]>]

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


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]