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

Sandeep Kumar <ietf@sandeep.de> Fri, 09 December 2016 08:13 UTC

Return-Path: <ietf@sandeep.de>
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 A2F4812A19D; Fri, 9 Dec 2016 00:13:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sandeep.de
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 kNhzJcuRi0G2; Fri, 9 Dec 2016 00:12:59 -0800 (PST)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19FDA12A192; Fri, 9 Dec 2016 00:12:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1481271175; l=11443; s=domk; d=sandeep.de; h=Content-Type:Cc:To:Subject:Date:From:References:In-Reply-To: MIME-Version; bh=jZDElEKRS7vQYNdGdqvR7hCMzGJAC8RutihCTnJS2EE=; b=V8+A0P22Q9NLu1+4NyfRFWMDHb2gKl7ngweypAzI5rmyHRELq2BqiHHxQQQ43ACmMY lZuVmKpJpuIoGjncZCvTOpJolySySNWs9yMm7hdYdRIVzwdo19rk6OszotvFqOmneYNh KYpScTMYWKORhbmFLjctrTtU24Jz9Wj+qzmVA=
X-RZG-AUTH: :JWkQc2C7evFfytIRBe7p82UYMzBqkr+YiXEkNEKLhUifTGQRFYQZmh2f
X-RZG-CLASS-ID: mo00
Received: from mail-qk0-f173.google.com ([209.85.220.173]) by smtp.strato.de (RZmta 39.10 AUTH) with ESMTPSA id t03c5asB98CsJck (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp384r1 with 384 ECDH bits, eq. 7680 bits RSA)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verification FAILED - unable to get local issuer certificate)) (Client hostname not verified); Fri, 9 Dec 2016 09:12:54 +0100 (CET)
Received: by mail-qk0-f173.google.com with SMTP id q130so10398010qke.1; Fri, 09 Dec 2016 00:12:54 -0800 (PST)
X-Gm-Message-State: AKaTC01EtXvCHh9f8C0ipQipDiR64G6BR6iKoAwCl4yAXxoQ5tudctDbYHJDvSd+biflWJ7F1G2erXhtj2r0tA==
X-Received: by 10.55.43.29 with SMTP id r29mr66929057qkh.211.1481271173885; Fri, 09 Dec 2016 00:12:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.97.33 with HTTP; Fri, 9 Dec 2016 00:12:53 -0800 (PST)
In-Reply-To: <d9aba3a07d14400f88f22329abc00128@XCH-ALN-010.cisco.com>
References: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.com> <14831.1481139454@obiwan.sandelman.ca> <d9aba3a07d14400f88f22329abc00128@XCH-ALN-010.cisco.com>
From: Sandeep Kumar <ietf@sandeep.de>
Date: Fri, 9 Dec 2016 09:12:53 +0100
X-Gmail-Original-Message-ID: <CAH51uSdK_BHgFKXzpp2XJ4H9fEqkkLynFLjV5PTn6Y8EHSFz-g@mail.gmail.com>
Message-ID: <CAH51uSdK_BHgFKXzpp2XJ4H9fEqkkLynFLjV5PTn6Y8EHSFz-g@mail.gmail.com>
To: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
Content-Type: multipart/alternative; boundary=001a1147e8e422baba05433552f8
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/hxrO_rR8J6v8RLVUoo4WdMi3x9c>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "anima-bootstrap@ietf.org" <anima-bootstrap@ietf.org>, Sandeep Kumar <sandeep.kumar@philips.com>, "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
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, 09 Dec 2016 08:13:06 -0000

HI Michael

 Just to add, 6tisch has decided to use OSCOAP as the transport but other
external standards like Fairhair and Thread have already decided to use
DTLS as the transport for EST since it is already there and does not break
the workflow the way it might in 6tisch. So these draft on DTLS transport
do solve the problem for some, not for everyone.

 Kind regards

Sandeep



On Fri, Dec 9, 2016 at 7:04 AM, Panos Kampanakis (pkampana) <
pkampana@cisco.com> wrote:

> Hi Michael,
>
> This are interesting good points.
>
> IMO, draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-est do not
> necessarily need to define one transport mechanism. COAPS (over DTLS) is
> one obvious option but running over OSCOAP with EDHOC is another. One of
> the goals of these drafts (would need to be merged) is the binding between
> COAP messages and BRSKI / EST APIs for all the bootstrapping and cert
> enrollment transactions defined in the anima-bootstrapping-keyinfra doc and
> RFC7030. draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-est
> address DTLS as transport mechanism right now, but could be expanded to
> define more than one transports. If the WG finds that as a better idea,
> normative language would need to be carefully of course and maybe an MTI
> option would need to be chosen.
>
> 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?
>
> 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?
>
> 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.
>
> Rgs,
> Panos
>
> -----Original Message-----
> From: Anima-bootstrap [mailto:anima-bootstrap-bounces@ietf.org] On Behalf
> Of Michael Richardson
> Sent: Wednesday, December 07, 2016 2:38 PM
> To: ace@ietf.org; 6tisch@ietf.org; 6tisch-security@ietf.org;
> anima-bootstrap@ietf.org
> Subject: Re: [Anima-bootstrap] [Ace] EST over CoAP in ACE wg
>
>
> I have read:
>     draft-pritikin-coap-bootstrap
> and draft-vanderstock-core-coap-est
>
> and over in the 6tisch security design team we have been trying to adapt
> the ANIMA WG draft-ietf-anima-bootstrapping-keyinfra for use in the
> 6tisch environment as a zero-touch enrollment process.
> (Yes, I am an author involved in both WGs)
>
> Peter (one of the authors of draft-vanderstock-core-coap-est) and Max
> (author of draft-pritikin-coap-bootstrap) are involved.
>
> Both documents have good content, and we could combine them easily and
> wind up with a relatively straight forward description of how to run EST
> over COAPS.
> But I don't think that this really solves the problems that we have.
>
> However, the movement in
>          draft-vucinic-6tisch-minimal-security (as phase 2, and one-touch)
> and   draft-richardson-6tisch-dtsecurity-secure-join (as phase 1,
> zero-touch)
> [both of which are being considered for adoption]
>
> is to move away from DTLS and towards OSCOAP and EDHOC.
>
> As such, what we would really like is an EST-like mechanism which runs
> over OSCOAP with EDHOC keying.  Ideally, it would also permit the process
> to be managed/initiated from the new device (the pledge), or from the JCE
> (Registrar, which might also be the AS in ACE terminology).
>
> We want to initiate from the JCE so that we can:
>   a) simplify the constrained device.
>   b) manage the order and priority of join activities to avoid
>      network congestion in constrained (mesh) networks.
>
> On the other hand, some want a really simple system that can be used with
> PSKs as authentication, with the new nodes initiating.
>
> I wrote this email last week to explain some of what I have in mind.
>   https://www.ietf.org/mail-archive/web/6tisch/current/msg05020.html
>
> I don't know if the EST work fits into ACE's charter, but given that ACE
> is where OSCOAP and EDHOC seem to be, I'm happy to work on a document here.
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works  -=
> IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>