Subject: Re: [6tisch] [Ace] EST over CoAP in ACE wg

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Dec 2016 14:37:34 -0500

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: peter van der Stok <[email-masked]>
Date: Thu, 08 Dec 2016 09:12:14 +0100

Hi Michael,

> (Registrar, which might also be the AS in ACE terminology).
About yesterday I started to understand the approach you suggest.
Just some more information, to be absolutely sure about what you 
propose.

Do you propose to keep the content formats used by EST unchanged?
and keep all the different modes specified in EST RFC?

Greetings,

Peter

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 9 Dec 2016 06:04:21 +0000

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:[email-masked]] On Behalf Of Michael Richardson
Sent: Wednesday, December 07, 2016 2:38 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Anima-bootstrap] [Ace] EST over CoAP in ACE wg

I have read:

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

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

On the other hand, some want a really simple system that can be used with PSKs as authentication, with the new nodes initiating.

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 <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Sandeep Kumar <[email-masked]>
Date: Fri, 9 Dec 2016 09:12:53 +0100

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) <
[email-masked]> wrote:

> 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
>
> the ANIMA WG draft-ietf-anima-bootstrapping-keyinfra for use in the
> 6tisch environment as a zero-touch enrollment process.
> 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.
> 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.
>
> --
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>