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-boun...@ietf.org] On Behalf Of Michael Richardson Sent: Wednesday, December 07, 2016 2:38 PM To: ace@ietf.org; 6ti...@ietf.org; 6tisch-secur...@ietf.org; anima-bootst...@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+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
