Subject: Re: [6tisch] xxx-bootstrap

From: peter van der Stok <[email-masked]>
Date: Thu, 01 Dec 2016 09:39:50 +0100

Hi Michael,

thanks for a clear answer.
> 
> I think the Registrar/JCE will need to support three protocols:
> 
> 1) a push protocol over CoAP.
> 2) a pull protocol (RFC7030/EST).
> 3) a protocol to talk to the MASA (TBD)
> 

As discussed earlier, having a push/pull agnostic protocol would be 
nice. (and probably feasible)
As stated earlier, I think that discovery and which node starts the 
bootstrap protocol (BRSKI) is very much installation/technology 
dependent, and should be done in another document.

My intention was to reduce the coding effort of the registrar by making 
1) and 2) as similar as can be hoped for;
while payload considerations are of secondary importance.
My hope being that a manufacturer will deliver a registrar box 
supporting both coap and http versions.

When the consensus is that adding coap is already such an extra effort 
that code sharing between http and coap versions does not alleviate the 
effort,
then any solution for coap that concentrates on payload reduction is 
fine by me.

Peter

---

From: peter van der Stok <[email-masked]>
Date: Thu, 01 Dec 2016 10:01:57 +0100

Hi Michael,

all in favor of one approach to merge the push/pull aspects. (I have to 
understand the protocol exchange below, but it looks feasibale)
I am not sure about understanding EDHOC, but may be that is not 
important.

I still see all the mime formats. is that phase 1?
Is phase 2 then switching to OSCOAP with a single format containing 
binary encoding?

cheerio, and thanks for your explanation.

Peter

Michael Richardson schreef op 2016-12-01 01:18:
> Hi, I haven't read the entire thread yet, but I wanted to pull out 
> another
> email from a private thread about some ideas I had before I forgot.
> 
> This would be the phase 1.  Now that I understand more about EDHOC,
> I think that the certificate exchange and EDHOC setup would occur
> at the GET /nonce phase.
> 
> Peter, if this is what you have in mind, then let's develop one of the
> EST/CoAP drafts into saying this.
> 
> ====
> 
> I am thinking about if we can come up with a mechanism that can be 
> driven by
> either side, which uses the same protocol and message encodings.
> I had been thinking last night that CMS was getting in the way, but I
> think that actually that's probably not the case; we are going to use
> pkcs7/11 anyway, and if that's really the extent of it, then no big 
> deal.
> 
> I'm trying to find a way to merge this into netconf-keystore 
> essentially, and
> that document is not really particular about the formats.
> 
> I'm looking at draft-ietf-anima-bootstrapping-keyinfra-04 section 5.7,
> and EST section 4.
> 
> I imagine that one can reverse the process in 6tisch, and we could POST
> From the JCE to client /cacerts, etc...
> 
> So, if the straight EST process looks like:
> 
>     new-node                     registrar
>          POST /requestaudittoken-->     [includes nonce]
>          <--- 200 OK + audit token-     [section 5.2]
> 
>          GET /cacerts ----------->
>          <--- domain certificate--     (application/pkcs7-mime,
>                                         CMC Simple PKI RESPONSE)
>          GET /csrattrs ---------->
>          <--- app/csrattrs -------     [ASN as per 7030]
> 
>          POST /simpleenroll------>     (PKCS#10 Cert Req)
>          <--- LDevID cert---------     (pkcs7)
> 
> 
> Then the JCE driven process should instead look like:
> 
>     pledge                       JCE
>          <--- CoAP GET /nonce-----
>          ----- 200 OK, nonce ---->     [could be empty if nonce
> 
>          <--- CoAP POST /voucher--     {audit token or ownership 
> voucher}
>          ----- 200 OK------------>     [or 4xx or 5xx code! ]
> 
>          <--- CoAP POST /cacerts--     [block-transfer]  [maybe not??]
>                                        (application/pkcs7-mime,
>                                         CMC Simple PKI RESPONSE)
>          ----200 OK-------------->
> 
>          <--- CoAP POST /csrattrs-     [ASN as per 7030]
>          ----200 OK-------------->
> 
>          <--- CoAP GET  /csr------
>          ----200 OK ---PKCS10 ----     [PKCS#10 Cert Req]
> 
>          <--- CoAP POST /cert-----     [PKCS7 Certificate]
>          ----200 OK --------------
> 
> Except that ideally, the above would be described in YANG with Kent's 
> help
> in netconf-keystore.
> (Pascal, in our SoW #7, the above protocol would be Deliverable 3, btw)
> 
> 
> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-

---

From: Göran Selander <[email-masked]>
Date: Fri, 2 Dec 2016 15:12:44 +0000

Hi Peter,

>I am not sure about understanding EDHOC, but may be that is not

EDHOC is a key exchange protocol, analogous to the TLS handshake, but with
less features. It allows authentication based on pre-shared keys, raw
public keys or X.509 certificates. The protocol messages are encoded in
CBOR and using COSE, and not bound to a specific protocol layer. The EDHOC
protocol messages may be carried with CoAP and this has two advantages:

- EDHOC can be run between JN and JCE without the JN and JCE knowing each
others IP addresses using the same construction as with OSCOAP end-to-end
in the minimal security draft.

- CoAP and COSE are used both by OSCOAP and EDHOC, and the additional code
footprint for EDHOC will be small.

If you are interested in a simple lightweight enrolment protocol, EDHOC
and OSCOAP may be used for that. For authentication of enrolment using
e.g. manufacturer certificates, you may run EDHOC and OSCOAP in sequence
and carry the PKCS#10 in the OSCOAP request and the certificate issued
with the OSCOAP response, in total 2 round-trips (not considering
additional messages for delayed responses, CoAP response code 2.06 etc.).
For PSK authenticated enrolment it may suffice with one round-trip, the
OSCOAP request/response. These examples are JN-initiated, but similar
setup is possible for the JCE-initiated variant.

Note that this would not at all be as elaborate as the anima work, but
just as a comparison.

Have a nice week-end!

Göran

---

From: peter van der Stok <[email-masked]>
Date: Mon, 05 Dec 2016 09:15:12 +0100

Hi Goran,

thanks for this low overhead and clear explanation.

> Note that this would not at all be as elaborate as the anima work, but
I don't think EDHOC is meant to replace EST or the anima work.

It is a proposal to replace the EST part of the anima bootstrap by 
something targeted to the bootstrap case and use of CoAP for low 
resource devices without human intervention.

Peter

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Dec 2016 12:53:06 -0500

replying to three of your messages, and trying to repoint the thread at
6tisch-security.

peter van der Stok <[email-masked]> wrote:
    > I am not sure about understanding EDHOC, but may be that is not important.

I think it is.

    > I still see all the mime formats. is that phase 1?

They are HTTP content-types really.
That's part of of the phase 2.

    > Is phase 2 then switching to OSCOAP with a single format containing binary
    > encoding?

No, we would use EDHOC to create a secure session, and then we would run
our EST-CoAP-variant over that. No DTLS at all.

    > I don't think EDHOC is meant to replace EST or the anima work.

EDHOC doesn't replace EST, it replaces DTLS.

    > As stated earlier, I think that discovery and which node starts the bootstrap
    > protocol (BRSKI) is very much installation/technology dependent, and should
    > be done in another document.

I feel very much like I am the holdout for having the JCE initiate the join
protocol.

    > My intention was to reduce the coding effort of the registrar by making 1)
    > and 2) as similar as can be hoped for;
    > My hope being that a manufacturer will deliver a registrar box supporting
    > both coap and http versions.

    > When the consensus is that adding coap is already such an extra effort that
    > code sharing between http and coap versions does not alleviate the effort,
    > then any solution for coap that concentrates on payload reduction is fine by
    > me.

I can see an implementation where a front-end requests/processes the PKCS
format messages in traditional EST and the CoAP push/pull variants, and then
feeds it into the same engine.

I think that the biggest interoperability problem that we are going to have
is in the step where the Registrar/JCE tells the Pledge what to put in it's
CSR. This is because this part probably involves doing real ASN.1 work, and
pledges will want none of that.

---

From: Göran Selander <[email-masked]>
Date: Tue, 6 Dec 2016 19:03:39 +0000

Apologies for the previous empty mail, this is the mail I wanted to
comment on.

On 2016-12-01 01:18, "6tisch on behalf of Michael Richardson"
<[email-masked] on behalf of [email-masked]> wrote:

>
>Hi, I haven't read the entire thread yet, but I wanted to pull out another
>I am thinking about if we can come up with a mechanism that can be driven
>by
>pkcs7/11 anyway, and if that's really the extent of it, then no big deal.
>
>I'm trying to find a way to merge this into netconf-keystore essentially,
>and
>         <--- CoAP POST /voucher--     {audit token or ownership voucher}

In the interest of reducing round-trips, could anything of this be sent in
parallel with the key exchange?

Göran

>Except that ideally, the above would be described in YANG with Kent's help
>in netconf-keystore.

---

From: peter van der Stok <[email-masked]>
Date: Thu, 15 Dec 2016 09:56:18 +0100

Hi Malisa,

I read the 6tisch-minimal-security draft.
I do have some detailed questions, which probably have to do with my 
reading things which are not there.

If I understand correctly, the Join response returns the link2 keys to 
secure the the links between JN, JA and possibly other neighbours of JN.
Consequently, that means during the whole bootstrap process the link 
between JA and JN is not secured by layer2 keys.
My question concerns step 2 , neghbour discovery.
It is mentioned that ND is executed, but it is not clear to me how that 
works in detail.
The whole 6tisch network uses link-layer protection, while JA-JN link is 
not protected; Does that not need an additional protocol specifications 
for JA?

Do I understand correctly that during discovery the prefix is received 
and a global IP address is constructed to be used for the JOIN request?

A more global related question is why can you not transmit link-layer 
keys to be used for JA-JN link after the security handshake and then 
start ND?

Other questions:
Do you expect the JCA to be on the 6tisch network or can it be anywhere 
else?
What about securing a heterogeneous network of which the 6tisch network 
happens to be part? The link-layer keys will not be adequate in that 
case.

Thanks for answering,

Peter

Mališa Vučinić schreef op 2016-11-30 13:50:
> Hi Peter,
> 
> Yes, that is correct, we propose to use OSCOAP for communication
> between JN and JCE. In the model, JA is a CoAP proxy so the choice of
> OSCOAP and EDHOC was quite natural. We use CBOR/COSE to transport the
> keys and the short 15.4 address. Certificate enrollment belongs to
> Phase 1, and at the moment we don’t have the details on how this is
> done but hopefully we can come to an agreement to use the common
> protocols for both phases such that Phase 2 is a natural extension of
> Phase 1.
> 
> First step in that direction could be to discuss the most efficient
> way of JA forwarding. We decided against IP-in-IP encapsulation
> because it results in three IP headers in the constrained part in case
> JCE is not collocated with 6LBR. Having JA play the role of a CoAP
> proxy is a plausible alternative.
> 
> Mališa
> 
>> On 30 Nov 2016, at 11:07, peter van der Stok <[email-masked]> 
>> wrote:
>> 
>> Hi Malisa,
>> 
>> thanks for the answer. I am happy to read that there is a shared 
>> concern about reuse.
>> 
>> My concern is the communication between joining node and central node.
>> 
>> Did I understand correctly that you propose to use oscoap for the 
>> communication between joning node and central node?
>> what content-formats do you propose to transport between joining node 
>> and central node? Will those be different in phase 1 and 2?
>> What contents do you propose to transport? certificates, YANG/CBOR 
>> documents, keys?
>> How should I see the co-existence between phase 1 and phase 2? Will 
>> phase 2 be an extension of the transported contents of phase 1?
>> Apologies for the naivety of my questions, but the number of discussed 
>> possibilities at this moment are quite overwhelming.
>> 
>> I just like to get clear how the bootstrap can be composed of 
>> different standardized parts and where the future evolution is.
>> Identifying and describing those parts will be a nice step forward.
>> 
>> Peter
>> 
>> 
>> Mališa Vučinić schreef op 2016-11-30 10:22:
>>> Hello Peter,
>>> My understanding of the IETF 97 meeting outcome is that Phase 1
>>> solution will be anima-compatible i.e., it will provide zero-touch
>>> bootstrapping with manufacturer-installed certificate as the start
>>> state and locally relevant credential as the end state. At the 
>>> moment,
>>> I believe that Michael’s proposal for Phase 1 is quite 6tisch 
>>> agnostic
>>> and it can be used in other scenarios.
>>> However, the end state of Phase 2 are 6tisch-specific key(s) (cf.
>>> minimal draft) and temporary network identifiers that we tackle in 
>>> the
>>> minimal-security draft. This builds upon existing work in 6tisch and
>>> will be needed no matter what common bootstrapping approach is used.
>>> Mališa
>>>> On 30 Nov 2016, at 09:06, peter van der Stok <[email-masked]> 
>>>> wrote:
>>>> Hi 6tisch bootstrap followers,
>>>> Curently, we live in a confusing world wih many bootstrap proposals.
>>>> They all seem to have in common; a joining node, an assistant, a 
>>>> central authority, and Michael Richardson.
>>>> While each bootstrap proposal seems to have a different naming 
>>>> history.
>>>> Joking apart, I like to plead for a commmon bootstrap approach in 
>>>> 6tisch, and anima to share parts of the bootstrap protocols.
>>>> I suspect that the discovery and the push- or pull start will be 
>>>> technology and context dependent.
>>>> My concern is with the number of protocols that the central 
>>>> authority has to support.
>>>> When there are too many bootstrap approaches, we may end up with as 
>>>> many protocol converters as there are bootstrap protocols.
>>>> The anima bootstrap team has recognized the importance of low 
>>>> resource devices by supporting the use of coap.
>>>> The drafts "EST over coaps" demonstrate that the support of two 
>>>> protocols (coap and http based) in the cental authority is 
>>>> realistic.
>>>> My plea is that we find a common protocol that replaces EST for the 
>>>> coap nodes.
>>>> I understand that after the bad experience with CoMI, the 6tisch 
>>>> people do not want to be dalayed again by waiting for a common 
>>>> approach.
>>>> Nevertheless, I think it is worthwhile to explore this avenue.
>>>> Any comments?
>>>> Peter
>>>> --
>>>> Peter van der Stok
>>>> _______________________________________________
>>>> 6tisch mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 15 Dec 2016 11:19:46 +0100

Hi Peter,

Thanks for your comments. See my responses inline.

Mališa

> On 15 Dec 2016, at 09:56, peter van der Stok <[email-masked]> wrote:
> 
> Hi Malisa,
> 
> I do have some detailed questions, which probably have to do with my reading things which are not there.
> 
> If I understand correctly, the Join response returns the link2 keys to secure the the links between JN, JA and possibly other neighbours of JN.

Yes, that’s correct.

> Consequently, that means during the whole bootstrap process the link between JA and JN is not secured by layer2 keys.

This is still under discussion within the design team, but the conclusion is the same — we can’t provide any L2 security at that point because L2 keys are simply not known. One option is to use well-known K1 to provisionally protect the join packets at L2 but this of course does not provide any security other than helping to bootstrap L2. Another option is for JA to simply accept unsecured packets at L2, and make it an exception for join traffic, potentially only during the duration of the join process.

> It is mentioned that ND is executed, but it is not clear to me how that works in detail.

Yes, that needs more work. Will create an issue to update it in the next version. The ND at that point refers to a registration of JN’s link-local address at JA, in order to bootstrap the neighbor tables in IPv6 compliant way. So, in summary it refers to a single NS/NA exchange between JN and JA.

> The whole 6tisch network uses link-layer protection, while JA-JN link is not protected; Does that not need an additional protocol specifications for JA?

In Section 5, we state: 

"The JN uses the initial key K1 [I-D.ietf-6tisch-minimal] until it is configured with a new link-layer key K2 as described above. JA SHOULD secure/verify DATA and ACKNOWLEDGMENT frames destined/originated at JN with K1 only during the duration of the join process.  How JA learns whether the join process is ongoing is out of scope of this specification."

Again, instead of K1 the frames between JN and JA could simply be unsecured at L2. Is this what you are referring to or would you like to see other text added? 

> Do I understand correctly that during discovery the prefix is received and a global IP address is constructed to be used for the JOIN request?

No, there is no prefix information distributed at that time. This happens after the node has joined. JOIN request is sent link-local to link-local from JN to JA, and using global addresses from JA to JCE (possible because JA is already part of the network). Will clarify.

> A more global related question is why can you not transmit link-layer keys to be used for JA-JN link after the security handshake and then start ND?

As stated above, ND at that point refers to NS/NA exchange in order to register link-local address of JN before it should start sending IPv6 packets from the interface. RPL DIOs which contain prefix information are encrypted using K2 and can only be decrypted once the node has joined.

But you are right, we may not need the NS/NA exchange in case minimal-security follows Phase 1, assuming it has been done before. Will clarify in the next version.

> Other questions:
> Do you expect the JCA to be on the 6tisch network or can it be anywhere else?

There is no reason why JCE would need to be collocated with 6LBR. It suffices that JA knows JCE’s global address for the communication to take place. 

> What about securing a heterogeneous network of which the 6tisch network happens to be part? The link-layer keys will not be adequate in that case.

I don’t understand the use case, could you provide some more details? 

>>> On 30 Nov 2016, at 11:07, peter van der Stok <[email-masked]> wrote:
>>> Hi Malisa,
>>> thanks for the answer. I am happy to read that there is a shared concern about reuse.
>>> Did I understand correctly that you propose to use oscoap for the communication between joning node and central node?
>>> what content-formats do you propose to transport between joining node and central node? Will those be different in phase 1 and 2?
>>> What contents do you propose to transport? certificates, YANG/CBOR documents, keys?
>>> How should I see the co-existence between phase 1 and phase 2? Will phase 2 be an extension of the transported contents of phase 1?
>>> Apologies for the naivety of my questions, but the number of discussed possibilities at this moment are quite overwhelming.
>>> I just like to get clear how the bootstrap can be composed of different standardized parts and where the future evolution is.
>>>> state and locally relevant credential as the end state. At the moment,
>>>> I believe that Michael’s proposal for Phase 1 is quite 6tisch agnostic
>>>> minimal draft) and temporary network identifiers that we tackle in the
>>>>> On 30 Nov 2016, at 09:06, peter van der Stok <[email-masked]> wrote:
>>>>> They all seem to have in common; a joining node, an assistant, a central authority, and Michael Richardson.
>>>>> While each bootstrap proposal seems to have a different naming history.
>>>>> Joking apart, I like to plead for a commmon bootstrap approach in 6tisch, and anima to share parts of the bootstrap protocols.
>>>>> I suspect that the discovery and the push- or pull start will be technology and context dependent.
>>>>> My concern is with the number of protocols that the central authority has to support.
>>>>> When there are too many bootstrap approaches, we may end up with as many protocol converters as there are bootstrap protocols.
>>>>> The anima bootstrap team has recognized the importance of low resource devices by supporting the use of coap.
>>>>> The drafts "EST over coaps" demonstrate that the support of two protocols (coap and http based) in the cental authority is realistic.
>>>>> My plea is that we find a common protocol that replaces EST for the coap nodes.
>>>>> I understand that after the bad experience with CoMI, the 6tisch people do not want to be dalayed again by waiting for a common approach.

---

From: peter van der Stok <[email-masked]>
Date: Fri, 16 Dec 2016 09:17:04 +0100

Hi Malisa,

Just one point to understand the temporary secure link between JN and 
JA.

> This is still under discussion within the design team, but the
> conclusion is the same — we can’t provide any L2 security at that
> point because L2 keys are simply not known. One option is to use
> well-known K1 to provisionally protect the join packets at L2 but this
> of course does not provide any security other than helping to
> bootstrap L2. Another option is for JA to simply accept unsecured
> packets at L2, and make it an exception for join traffic, potentially
> only during the duration of the join process.
> 
I like to state the objectives of the "temporary secure link" (TSL) 
between JA and JN as I see them.
Sorry for stating the obvious.

The security objectives for the TSL are:
(1) When the JN is correct, malicious nodes cannot decode the key 
exchange between JN and JCA or replay them.
(2) When the JN is malicious,
(2.1) the TSL keys cannot be used to decode the key exchange over other 
TSL's or replay them.
(2.2) the TSL MUST be restricted to a set of messages to prevent the 
malicious node from misusing the network.

Protocol choices are:
The selection and generation of TSL keys.
The selection and enforcement of message sets.

Do you agree? Is there more?
I repeat these objectives because especially objective 2.2 seems to be 
silently understood or ignored; although you seem to mention them in the 
text above.

Selecting messages on destination address in JA, may allow setting up a 
path between JN and JCA where JN uses a global address, provided by JA.
That will simplify the replacement of EST over CoAPs by your EDHOC, 
OSCOAP protocol and vice versa.

As expressed earlier, I like to define separate protocol parts which can 
be changed during technology evolution.
Is that a design consideration you want to take into account?

Peter

---

From: Mališa Vučinić <[email-masked]>
Date: Fri, 16 Dec 2016 13:46:16 +0100

Hi Peter,

See inline.

Mališa

> On 16 Dec 2016, at 09:17, peter van der Stok <[email-masked]> wrote:
> 
> Hi Malisa,
> 
> Just one point to understand the temporary secure link between JN and JA.
> 
> I like to state the objectives of the "temporary secure link" (TSL) between JA and JN as I see them.
> (1) When the JN is correct, malicious nodes cannot decode the key exchange between JN and JCA or replay them.
> (2.1) the TSL keys cannot be used to decode the key exchange over other TSL's or replay them.
> (2.2) the TSL MUST be restricted to a set of messages to prevent the malicious node from misusing the network.
> 
> Protocol choices are:
> I repeat these objectives because especially objective 2.2 seems to be silently understood or ignored; although you seem to mention them in the text above.

We seem to diverge around the ‘security’ notion of the Temporary Secure Link (TSL) between JN and JA. Instead of TSL, I would rather call it Temporary Insecure Link (TIL), because that’s what it really is — insecure. 

JA is considered untrusted so it cannot authenticate or moreover authorize JN to join the network so that it must accept frames from any JN. Note that there is no PSK or RPK available on JA, and in case of certificates any node under a common CA would authenticate while in case of Phase 1, JN and JA wouldn’t even have a common CA. That said, in case JN is malicious, it can inject frames at will, being it the replay of another session or simply bogus traffic, the defense against which is to implement rate limiting at JA and detect it at JCE. Therefore, I question the need for (2.1). 

As per objective (1), this is met already as malicious nodes cannot decode the key exchange since it is protected end-to-end. They are able to record the exchange on TIL and replay it to another JA but this will be rejected by the JCE. 

> Selecting messages on destination address in JA, may allow setting up a path between JN and JCA where JN uses a global address, provided by JA.

The problem I see there is that we would need to provide a network prefix to JN before it has joined the network, which is a privacy threat. Right?

> That will simplify the replacement of EST over CoAPs by your EDHOC, OSCOAP protocol and vice versa.
> 
> As expressed earlier, I like to define separate protocol parts which can be changed during technology evolution.

Definitely. It would be helpful if you could go through the draft and identify the points that you consider as problematic with respect to future evolution of TSCH/6TiSCH.