Re: [6tisch] xxx-bootstrap

peter van der Stok <stokcons@xs4all.nl> Thu, 01 December 2016 09:04 UTC

Return-Path: <stokcons@xs4all.nl>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18386129CA1 for <6tisch@ietfa.amsl.com>; Thu, 1 Dec 2016 01:04:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hj0oLZhkMVx5 for <6tisch@ietfa.amsl.com>; Thu, 1 Dec 2016 01:04:13 -0800 (PST)
Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE2D129CA6 for <6tisch@ietf.org>; Thu, 1 Dec 2016 01:01:58 -0800 (PST)
Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:208]) by smtp-cloud3.xs4all.net with ESMTP id EZ1x1u00C4ydcfa01Z1xpn; Thu, 01 Dec 2016 10:01:57 +0100
Received: from 2001:983:a264:1:482f:dfa5:11e6:f340 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 01 Dec 2016 10:01:57 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Thu, 01 Dec 2016 10:01:57 +0100
From: peter van der Stok <stokcons@xs4all.nl>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <31466.1480551529@obiwan.sandelman.ca>
References: <efb18853e63642bc4a996dc419cd1efb@xs4all.nl> <31466.1480551529@obiwan.sandelman.ca>
Message-ID: <72f491eeb444448daa34196c9ac656ea@xs4all.nl>
X-Sender: stokcons@xs4all.nl (koHnQYGD6rdHM95oLoVKjWNAW4V5Tl84)
User-Agent: XS4ALL Webmail
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/ioqExauWRQmO2yPJIayB6kqO5VE>
Cc: 6tisch <6tisch@ietf.org>, sandeep kumar <sandeep.kumar@philips.com>, consultancy@vanderstok.org
Subject: Re: [6tisch] xxx-bootstrap
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: consultancy@vanderstok.org
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Dec 2016 09:04:18 -0000

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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-