Subject: Re: [6lo] FW: I-D Action: draft-ietf-6lo-plc-03.txt

From: "Liubing (Remy)" <[email-masked]>
Date: Thu, 21 May 2020 09:20:14 +0000

Hello Michael,

Is the following understanding correct? The difference between the "one-touch" and the "zero-touch" methods is that whether the key or certificate is provisioned by the manufacturer or by the operator at the deployment site. As long as the key/IDevID/certificate is provisioned before the device goes out of the factory, i.e., the operator doesn't have to provision/touch it on site to get it securely join the network, it can be considered as "zero-touch".

Even though the pledge ID is given privately by the manufacturer, and not as per 802.1 AR, the dtsecurity-zerotouch-join method can be implemented by using the MASA provided by the manufacturer? Is the dtsecurity-zerotouch-join method aimed at a scenario in which a certificate can't be provisioned a priori?

Many thanks.

Remy

-----邮件原件-----
发件人: Michael Richardson [mailto:[email-masked]] 
发送时间: 2020年5月20日 23:10
收件人: Liubing (Remy) <[email-masked]>; [email-masked]; Carles Gomez Montenegro <[email-masked]>
主题: Re: 答复: [6lo] FW: I-D Action: draft-ietf-6lo-plc-03.txt

Liubing (Remy) <[email-masked]> wrote:
    > Thank you for mentioning 6tisch-minimal-security.  There is also a
    > BRSKI-like 6tisch mechanism that uses IDevID.

    >   [Remy] I think you must
    > be talking about [draft-ietf-6tisch-dtsecurity-zerotouch-join]. The
    > minimal security is considered to be one-touch since the PSK has to be
    > configured a priori. And this document provides a zero-touch method, in
    > which the IDevID (provided by the manufacturer) in 802.1AR is used as
    > the credential for authentication. The authentication is done with the
    > help of the MASA. Am I understanding it correctly? I think the method
    > simplifies the provisioning procedure. However, the PLC standards have
    > not supported 802.1AR yet, thus this zero-touch method couldn't be used
    > in the implementation at this moment.

Whether or not the *PLC* documents specify 802.1AR is not really relevant.
They also don't specify any useful secure join mechanism at all.

The device either has a manufacturer provided keypair, or it has to be provisioned with a key by the operator.

    > Is it the case that the PLC devices can have no L2 security as an
    > option?  I believe that you may wish to outlaw that situation.

    > [Remy] All the PLC standards we mentioned in this document have L2
    > security mechanisms, such as encryption, data integrity, and
    > anti-replay. Since this document is focused on the adaptation layer and
    > above, the L2 security is considered to be applied by default.

Then uou can use dtsecurity-zerotouch-join or 6tisch-minimal-security.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 May 2020 10:59:31 -0400

Liubing (Remy) <[email-masked]> wrote:
    > Is the following understanding correct? The difference between the
    > "one-touch" and the "zero-touch" methods is that whether the key or
    > certificate is provisioned by the manufacturer or by the operator at
    > the deployment site. As long as the key/IDevID/certificate is
    > provisioned before the device goes out of the factory, i.e., the
    > operator doesn't have to provision/touch it on site to get it securely
    > join the network, it can be considered as "zero-touch".

Yes, that's correct. The touches by the manufacturer and/or a VAR don't count.
Or to put it another way, it's the number of touches the by operator that count.
A further characteristic MAY be that it doesn't matter which unit is shipped
to which customer from the warehouse.  (There seem to be use cases in transportation
and manufacturing where it matters due to contractual warantee issues.
I think because refurbished devices may mingle with brand-new devices in the
warehouse.  This is less interesting for enterprise routers and more relevant
for train braking systems)

    > Even though the pledge ID is given privately by the manufacturer, and
    > not as per 802.1 AR, the dtsecurity-zerotouch-join method can be
    > implemented by using the MASA provided by the manufacturer? Is the
    > dtsecurity-zerotouch-join method aimed at a scenario in which a
    > certificate can't be provisioned a priori?

dtsecurity-zerotouch-join assumes a certificate provisioned prior to deployment.
So I can't agree with the last sentence.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Liubing (Remy)" <[email-masked]>
Date: Fri, 22 May 2020 09:54:29 +0000

Hello Michael,

Thank you for your explanation.

I think I can rewrite some sentences in the security considerations. Please tell me the following text is correct or not.

It is highly recommended to conduct a mutual authentication between the network and the device tending to join in it. The authentication can be accomplished with the help of certificates or pre-shared keys [I-D.ietf-6tisch-minimal-security] provisioned by the operator at the deployment site. Alternatively, the certificates could be provisioned by the manufacturer or the vendor before the shipment, and in this case the authentication can be accomplished with the help of a MASA service on the Internet [dtsecurity-zerotouch-join].

Best regards.
Remy

-----邮件原件-----
发件人: Michael Richardson [mailto:[email-masked]] 
发送时间: 2020年5月21日 23:00
收件人: Liubing (Remy) <[email-masked]>; [email-masked]; Carles Gomez Montenegro <[email-masked]>
主题: Re: [6lo] FW: I-D Action: draft-ietf-6lo-plc-03.txt

Yes, that's correct. The touches by the manufacturer and/or a VAR don't count.
Or to put it another way, it's the number of touches the by operator that count.
A further characteristic MAY be that it doesn't matter which unit is shipped to which customer from the warehouse.  (There seem to be use cases in transportation and manufacturing where it matters due to contractual warantee issues.
I think because refurbished devices may mingle with brand-new devices in the warehouse.  This is less interesting for enterprise routers and more relevant for train braking systems)

---

From: Michael Richardson <[email-masked]>
Date: Fri, 22 May 2020 11:20:22 -0400

Liubing (Remy) <[email-masked]> wrote:
    > It is highly recommended to conduct a mutual authentication between the
    > network and the device tending to join in it. The authentication can be
    > accomplished with the help of certificates or pre-shared keys
    > [I-D.ietf-6tisch-minimal-security] provisioned by the operator at the
    > deployment site. Alternatively, the certificates could be provisioned
    > by the manufacturer or the vendor before the shipment, and in this case
    > the authentication can be accomplished with the help of a MASA service
    > on the Internet [dtsecurity-zerotouch-join].

I suggest:

An onboarding process is required to enabled a new PLC node to join the
network.  This is required in order for the new node to acquire the network
encryption key appropriate for the layer-2.
Automated processes perform a mutual authentication of network and new node.
Methods include protocols such as [I-D.ietf-6tisch-minimal-security] (which
uses pre-shared keys), and constrained variations of
[I-D.ietf-anima-bootstrapping-keyinfra] such
[I-D.ietf-6tisch-dtsecurity-zerotouch-join].
It is also possible to use EAP methods such as [I-D.ietf-emu-eap-noob] via
transports like PANA [RFC5191].  No specific mechanism is specified by
this document as an appropriate mechanism will depend upon deployment circumstances.

---

From: "Liubing (Remy)" <[email-masked]>
Date: Tue, 26 May 2020 07:46:33 +0000

Hello Michael,

Thank you for your suggestion. I prefer not to include [I-D.ietf-anima-bootstrapping-keyinfra], since it is not as directly related to PLC as [I-D.ietf-6tisch-dtsecurity-zerotouch-join]. How about make a very brief explanation just like you made for [I-D.ietf-6tisch-minimal-security]?

I post the second paragraph of the security considerations below. Please tell me your opinion. Thank you.

Malicious PLC devices could paralyze the whole network via DOS attacks, e.g., keep joining and leaving the network frequently, or multicast routing messages containing fake metrics. A device may also join a wrong or even malicious network, exposing its data to illegal users. Mutual authentication of network and new device can be conducted during the onboarding process of the new device. Methods include protocols such as [RFC7925] (exchanging pre-installed certificates over DTLS), [I-D.ietf-6tisch-minimal-security] (which uses pre-shared keys), and [I-D.ietf-6tisch-dtsecurity-zerotouch-join] (which uses IDevID and MASA service). It is also possible to use EAP methods such as [I-D.ietf-emu-eap-noob] via transports like PANA [RFC5191]. No specific mechanism is specified by this document as an appropriate mechanism will depend upon deployment circumstances. The network encryption key appropriate for the layer-2 can also be acquired during the onboarding process.

Best regards,
Remy

-----邮件原件-----
发件人: Michael Richardson [mailto:[email-masked]] 
发送时间: 2020年5月22日 23:20
收件人: Liubing (Remy) <[email-masked]>
抄送: [email-masked]; Carles Gomez Montenegro <[email-masked]>
主题: Re: 答复: [6lo] FW: I-D Action: draft-ietf-6lo-plc-03.txt

I suggest:

An onboarding process is required to enabled a new PLC node to join the network.  This is required in order for the new node to acquire the network encryption key appropriate for the layer-2.
Automated processes perform a mutual authentication of network and new node.
Methods include protocols such as [I-D.ietf-6tisch-minimal-security] (which uses pre-shared keys), and constrained variations of [I-D.ietf-anima-bootstrapping-keyinfra] such [I-D.ietf-6tisch-dtsecurity-zerotouch-join].
It is also possible to use EAP methods such as [I-D.ietf-emu-eap-noob] via transports like PANA [RFC5191].  No specific mechanism is specified by this document as an appropriate mechanism will depend upon deployment circumstances.