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 protected]> 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:[email protected]] On Behalf > Of Michael Richardson > Sent: Wednesday, December 07, 2016 2:38 PM > To: [email protected]; [email protected]; [email protected]; > [email protected] > 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 <[email protected]>, Sandelman Software Works -= > IPv6 IoT consulting =- > > > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
