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
