Subject: [6tisch] xxx-bootstrap

From: peter van der Stok <[email-masked]>
Date: Wed, 30 Nov 2016 09:06:10 +0100

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

---

From: Mališa Vučinić <[email-masked]>
Date: Wed, 30 Nov 2016 10:22:58 +0100

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:
> 
> They all seem to have in common; a joining node, an assistant, a central authority, and Michael Richardson.
> 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.
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: peter van der Stok <[email-masked]>
Date: Wed, 30 Nov 2016 11:07:59 +0100

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
> 
>> They all seem to have in common; a joining node, an assistant, a 
>> central authority, and Michael Richardson.
>> When there are too many bootstrap approaches, we may end up with as 
>> many protocol converters as there are bootstrap protocols.
>> 
>> 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: Mališa Vučinić <[email-masked]>
Date: Wed, 30 Nov 2016 13:50:34 +0100

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 30 Nov 2016 19:18:49 -0500

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: Michael Richardson <[email-masked]>
Date: Wed, 30 Nov 2016 19:30:12 -0500

> My concern is with the number of protocols that the central authority has to

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)

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

My impression, is that the CoMI work wasn't a bad experience, it was just too
complex to fit it into 15.4 Information Elements.  I think some of the issue
was trying to automate the YANG->CoAP mapping.  At least, that's what I observed.