IETF Logo Mail Archive

Re: [Ace] [Anima-bootstrap] EST over CoAP in ACE wg

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 10 March 2017 15:33 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D123129639; Fri, 10 Mar 2017 07:33:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 R5qGmbuHMLVN; Fri, 10 Mar 2017 07:32:59 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D09E12964B; Fri, 10 Mar 2017 07:32:55 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 81EDCE207; Fri, 10 Mar 2017 10:55:43 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5AA086381A; Fri, 10 Mar 2017 10:32:54 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
In-Reply-To:
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Fri, 10 Mar 2017 10:32:54 -0500
Message-ID: <14839.1489159974@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/oQJ9nn9FLMqFuuORBcDSniub5NA>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "anima-bootstrap@ietf.org" <anima-bootstrap@ietf.org>, "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "ace@ietf.org" <ace@ietf.org>
Subject: Re: [Ace] [Anima-bootstrap] EST over CoAP in ACE wg
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: 6tisch-security@ietf.org, anima-bootstrap@ietf.org
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Mar 2017 15:33:01 -0000

{to reply to an old email with some valid questions, and some questions of my
own.  I am also clipping the reply-To}

Panos Kampanakis (pkampana) <pkampana@cisco.com> wrote:
    > I am curious about your workflow in
    > https://www.ietf.org/mail-archive/web/6tisch/current/msg05020.html You
    > are envisioning for the JCE to initiate the bootstrapping to the
    > pledge, but wouldn't that better be defined in the
    > anima-bootstrapping-keyinfra doc?

Constrained bootstrap is not really in scope for ANIMA.
The general constrained bootstrap situation is too big, but 6tisch
constrains the possible solution space, which is why we feel that we can make
progress there.

So, I want to accomodate constrained bootstrap in anima-bootstrap, but
not define it.

    > About 'simple system that can be used with PSKs as authentication', I
    > was curious. Did you have TLS-PSK, or TLS-SRP or OSCOAP message auth
    > with PSK/RPK/Cert? Anything more detail about these usecases?

This is being proposed as 6tisch-minimal-security, and it uses OSCOAP and EDHOC.

    > A nit in " <--- CoAP POST /cert----- [PKCS7 Certificate] ". That
    > message would require the private key to be included with the cert
    > since the pledge did not generate it by himself. EST defines CMS for
    > this message. PKCS12 could suffice here as well with the challenge if
    > the passphrase provisioning being the problem.

I'm not sure I understand this.
Why do you say that the pledge did not generate it by himself?
I"m assuming that it did so at manufacturing time, and that an IDevID
certificate was bound to the public part of the key.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email