Hi Toerless: > El 16 ago 2016, a las 7:43, Toerless Eckert <eck...@cisco.com> escribió: > > > Rafa, > > I have not managed to figure out from your draft what exactly > you consider to be bootstrapping. It seems you primarily refer > to draft-ohba-core-eap-based-bootstrapping, which seems to be expired.
Just a clarification, draft-marin-ace-wg-coap-eap-03 is just presenting a transport of EAP in CoAP (CoAP used as EAP lower-layer). The bootstrapping service is in the paper. > To quickly summarize what in anima we call bootstrap: > > The ANIMA key bootstrap protocol primarily tries to get a credential > installed on a device. This is based on RFC7030 (eg: cert enrolment) > and adds all the functions we have identified as being necessary on top of > this: > > 1. Initial signaling so the client can trust the server from which > it gets the credential - server can be from some owner of the > device and it's producing a credential from the vendor of the > device that makes the device trust the server. As a result > for example the client install the servers CA cert into its > cert trustpool list. > > 2. Requesting parameters to be associated with the credential. These > parameters are then useable by next steps. In Anima, these > credentials are parameters to the client cert, and those are > then used in building the ACP after bootstrap. > > 3. Installing the credential - in ANIMA devices the AN Certificate. > > Note: We did discuss but have not decided on options where > for example this step could be optional, eg: where in very low-end > devices the vendor installed credential is sufficient, and no new > credential is > desired, but instead only 1., 2., 4., 5. are performed. > > 4. Diagnostics so the server side will know if/how steps 1..3 where > successful. > > 5. Next step to take by the device - eg: build ACP or for non > ANIMA devices, maybe "here is your next provisioning connection > to build". (we're just discussing this step). > > So, i am not aware that existing EAP mechanisms offer any such bootstrap > functionality. I am not even aware they offer an equivalent of rfc7030 with > EAP. [Rafa] Thanks for this clear summary. I have to say that EAP is a protocol for authentication and key management mainly. You have several "EAP methods” that define the authentication mechanisms in EAP. As I mentioned, previous work about MIPv6 bootstrapping used tunneling capabilities in certain EAP methods to “inject” that configuration information (e.g. draft-giaretta-mip6-authorization-eap-04 , old draft but interesting). Other alternative is just to use EAP for authentication key material generation to protect the signaling of other protocol/s that allows to transfer the information you need. In the context of "IoT bootstrapping", I must say that we are not the only one proposing the usage of EAP (the novelty of our solution is the usage of CoAP as EAP lower-layer). Best Regards. > > > On Sun, Aug 14, 2016 at 02:05:14PM +0200, Rafa Marin Lopez wrote: >> Dear all: >> >> Related with the usage of CoAP for bootstrapping in constrained devices >> (using EAP and AAA infrastructures) we wrote this I-D: >> >> https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-03 >> >> and wrote this paper that may be of your interest: >> >> http://www.mdpi.com/1424-8220/16/3/358 >> >> Comments are welcome. >> >> Best Regards. >> >>> El 3 ago 2016, a las 15:55, Eliot Lear <l...@cisco.com> escribió: >>> >>> Dear authors of draft-ietf-anima-bootstrapping-keyinfra and WG, >>> >>> The Fairhair alliance focuses on lighting and building automation. Our >>> security team has been reviewing your draft, and we appreciate the >>> effort that you are devoting in this direction. We would just like to >>> highlight at this junction that there is a preference for device >>> communications from the autonomic device to the registrar to be via COAP >>> over DTLS rather than HTTP over TLS, primarily because the devices that >>> we are working with will already have a CoAP implementation. As such, >>> there is some interest in draft-pritikin-coap-bootstrap-03.txt. We look >>> forward to seeing that work further developed. >>> >>> On behalf of the Fairhair security subgroup, >>> >>> Eliot >>> >>> ps: as usual, I will encourage fairhair members to directly chime in >>> with their own views on this matter. >>> >>> >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >> >> ------------------------------------------------------- >> Rafael Marin Lopez, PhD >> Dept. Information and Communications Engineering (DIIC) >> Faculty of Computer Science-University of Murcia >> 30100 Murcia - Spain >> Telf: +34868888501 Fax: +34868884151 e-mail: r...@um.es >> ------------------------------------------------------- >> >> >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > > -- > --- > Toerless Eckert, eck...@cisco.com > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: r...@um.es ------------------------------------------------------- _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima