Re: [Anima] CoAP et al
Hi Michael: Just a clarification. If you are referring to IEEE 802.1X with 1x , then I have to say that IEEE 802.1X is not EAP but it is using EAP. More specifically, IEEE 802.1X is an EAP lower-layer. More comments inline. > El 16 ago 2016, a las 15:27, Michael Richardson > escribió: > > > Toerless Eckert wrote: >> 1. We did earlier in Anima investigate if/how we could/should use EAP >> to perform ANIMA bootstrap. It turned out that transporting all the >> desired key-infrastructure bootstrap messages across EAP would have > > There are two other key issues with the 1x-architecture of supplicants, > authenticators and authorization servers (AS). > > The architecture usually looks like: (nice picture at: > https://en.wikipedia.org/wiki/IEEE_802.1X ) > > S<--EAP-TLS over EAP over 1x/PANA->Authenticator<--EAP-over-radius-->AS > > The problem with this architecture is that it: > a) always creates state on the authenticator [Rafa] How do you perform an authentication exchange otherwise? Unless you are thinking something like Kerberos where the KDC is stateless. > > b) requires a secure relationship between Authenticator and Radius Server. > (a radius secret, and an entry in the Radius Server's client table) [Rafa] I think we should talk about AAA server in general because other protocols as Diameter can be used. Moreover the authenticator has to have a secure relationship with the next hop AAA server (AAA proxy) not with the (home) AAA server. Hence, the scalability. > > c) And we'd then have to run EST over the EAP/TLS connection, and do it > not with the radius server, but with the Registar. [Rafa] That is why I mentioned that, perhaps, the assistance of the EAP lower-layer (e.g. CoAP) could help with this task. > > (a) is a cost to absorb. > (b) could be mitigated by changing the Authenticator to really be: > > Authenticator . o O ( -EAP-over-GRASP--- ) > > and having no radius server at all. [Rafa] That is called in EAP: EAP Stand-Alone authenticator. > Of course, having got rid of that > compoennt, the commonality with the various 1x infrastructures is really > non-existant. All we've done is introduce EAP fragmentation (and code paths) > in a place where it will get used only once. > > Instead, a good way to think about ANIMA bootstrap is that it's the way in > which you get credentials which you can *then* use for 1x, if that's what > your infrastructure wants. > Today, those credentials are distributed > out-of-band. [Rafa] Precisely this is the kind of separation we are proposing in our work for IoT bootstrapping. Best Regards. > Seperating bootstrap from the 1x process not only simplifies > the bootstrap process, but it also simplifies the 1x code base, as it doesn't > have to figure out if the new pledge is trying to join the network, or trying > to bootstrap. > > (I'm reminded of the Robert Frost poem about The Road Not Taken. Often > it is thought to be about taking chances in life. I tend to think that > when it comes to security, that it's best not have divergent paths in code, > unless both have regularly used test cases: "I doubted if I should ever come > back") > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > ___ > 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: +3486501 Fax: +34868884151 e-mail: r...@um.es --- ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] CoAP et al
Hi Toerless: > El 16 ago 2016, a las 7:43, Toerless Eckert 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 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: +3486501 Fax: +34868884151 e-mail: r...@um.es >> --- >> >> >> >> >> ___
Re: [Anima] CoAP et al
Hi Toerless: > El 16 ago 2016, a las 7:26, Toerless Eckert escribió: > > Thanks, Rafa > > The combination of CoAP and EAP is certainly interesting. [Rafa] Thank you. > Let me > quickly summarize how in ANIMA we got to not consider EAP when we > looked at it without CoAP in the picture: > > 1. We did earlier in Anima investigate if/how we could/should use > EAP to perform ANIMA bootstrap. It turned out that transporting > all the desired key-infrastructure bootstrap messages across EAP > would have been quite cumbersome. It would have been necesssary to > use eg: EAP-TTLS which seems not to have seen wider use, and which would > have required to much around with the client side TLS stack (those > where the salient points if memory serves me right on this discussion). [Rafa] EAP can be used for authentication and because its well established key management framework (RFC 5247). However, the transport of additional information could be performed also by using the EAP lower-layer (e.g. CoAP), which makes the solution EAP method independent (e.g. EAP—TTLS is an EAP method). Having said this, I remember this was deeply discussed long time ago in the context of MIPv6 bootstrapping (RFC 4640): that is, 1) distributing bootstrapping information inside the EAP method, as you mention in EAP-TTLS (in general, a tunneled EAP method), or using another protocol after EAP authentication. In any case, in that time, the usage of AAA infrastructures for bootstrapping was considered. > > 2. Likewise, it seemed more appropriate for us to rely simply on IPv6 > link-local addressing to first exist on clients than to figure out how to > make sure L2-only solutions like EAPoL exist everywhere and would > work across all L2 media - and having to tie ANIMA code into > such L2 code. I can see how different industry groups that > specifically work only with one particular L2 technology are happy to > base more design on direct L2 layered protocols, but for ANIMA trying > to be easily applicable across any L2 technology, IPv6-LL seemed like > the best first approach. If specific L2 technologies have reasons > not to use it, i think we could add-on optimizations for those link > technologies. [Rafa] I agree with this. > > Cheers >Toerless > > 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 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: +3486501 Fax: +34868884151 e-mail: r...@um.es >> --- >> >> >> >> >> ___ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > > ___ > 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: +3486501 Fax: +34868884151 e-mail: r...@um.es --- ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] CoAP et al
Hi Brian: Thanks for the clarification. The only intention of my e-mail was to show that the usage of CoAP for bootstrapping (in constrained devices) was also considered in our work. The abstract you mention and the work you are doing in ANIMA are both fine with me. Best Regards. > El 16 ago 2016, a las 2:48, Brian E Carpenter > escribió: > > Let's be clear about the Anima context for "bootstrapping". You don't have > to look beyond the document abstract: > > " This document specifies automated bootstrapping of a remote secure > key infrastructure (BRSKI) using vendor installed IEEE 802.1AR > manufacturing installed certificates, in combination with a vendor > based service on the Internet." > > Obviously it's assumed that there is some kind of *insecure* connectivity > first. Which obviously implies a preceding insecure bootstrap of > some kind, but that is not the topic. > > And, repeating myself I think, Anima is primarily aimed at nodes that > manage devices, not at the devices themselves. However, we'd like BRSKI > to be available to all devices, hence Max wrote draft-pritikin-coap-bootstrap. > Again, please read the abstract: > > " This document provides an initial discussion of Bootstrapping of > Remote Secure key infrastructures (BRSKI) when the device being > bootstrapped speaks CoAP." > > Regards > Brian > > On 16/08/2016 11:58, Rafa Marin Lopez wrote: >> Hi Behcet: >> >>> El 15 ago 2016, a las 18:18, Behcet Sarikaya >>> escribió: >>> >>> Hi Rafa, >>> >>> On Sun, Aug 14, 2016 at 7:05 AM, 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 >>> >>> >>> Thanks for your work. >> >> [Rafa] Thanks for your comments. >>> >>> One thing I would like to clarify: >>> IoT bootstrapping should be done before the device gets an IP address. >> >> [Rafa] As you may know IPv6 link-local address may be used. I may agree with >> your statement in a “global” or “routable" IP address. But, I guess, it will >> depend on the scenario. In any case, I think we should first agree in what >> IoT bootstrapping means and what are the requirements (MAY, MUST, SHOULD, …) >> >>> I think that CoAP works over IP, i.e.e the device already has been >>> assigned an IP address. >> >> [Rafa] CoAP is being considered to be transported over the link-layer >> directly (e.g. draft-bormann-6lo-coap-802-15-ie-00 or >> draft-wang-6tisch-6top-coapie-01). Another example in LP-WAN >> (draft-pelov-core-cosol-01) >> >> Btw there are also other protocols working on top of UDP (as CoAP) >> considered to be transported directly over the link-layer (e.g. IKEv2) as >> you may know. >> >>> >>> So whatever you do can not be called bootstrapping maybe something >>> else which is security related, maybe some application layer key >>> establishment. >> >> [Rafa] For the reasons mentioned above, I still call it bootstrapping >> >> Best Regards. >> >>> >>> Regards, >>> >>> Behcet Comments are welcome. Best Regards. > El 3 ago 2016, a las 15:55, Eliot Lear 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: +3486501 Fax: +34868884151 e-mail: r...@um.es --- ___ Anima mailing list Anima@ietf.org https://www.ietf
Re: [Anima] CoAP et al
Toerless Eckert wrote: > 1. We did earlier in Anima investigate if/how we could/should use EAP > to perform ANIMA bootstrap. It turned out that transporting all the > desired key-infrastructure bootstrap messages across EAP would have There are two other key issues with the 1x-architecture of supplicants, authenticators and authorization servers (AS). The architecture usually looks like: (nice picture at: https://en.wikipedia.org/wiki/IEEE_802.1X ) S<--EAP-TLS over EAP over 1x/PANA->Authenticator<--EAP-over-radius-->AS The problem with this architecture is that it: a) always creates state on the authenticator b) requires a secure relationship between Authenticator and Radius Server. (a radius secret, and an entry in the Radius Server's client table) c) And we'd then have to run EST over the EAP/TLS connection, and do it not with the radius server, but with the Registar. (a) is a cost to absorb. (b) could be mitigated by changing the Authenticator to really be: Authenticator . o O ( -EAP-over-GRASP--- ) and having no radius server at all. Of course, having got rid of that compoennt, the commonality with the various 1x infrastructures is really non-existant. All we've done is introduce EAP fragmentation (and code paths) in a place where it will get used only once. Instead, a good way to think about ANIMA bootstrap is that it's the way in which you get credentials which you can *then* use for 1x, if that's what your infrastructure wants. Today, those credentials are distributed out-of-band. Seperating bootstrap from the 1x process not only simplifies the bootstrap process, but it also simplifies the 1x code base, as it doesn't have to figure out if the new pledge is trying to join the network, or trying to bootstrap. (I'm reminded of the Robert Frost poem about The Road Not Taken. Often it is thought to be about taking chances in life. I tend to think that when it comes to security, that it's best not have divergent paths in code, unless both have regularly used test cases: "I doubted if I should ever come back") -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] CoAP et al
On 8/16/16 10:06 AM, Toerless Eckert wrote:
> Thanks, Eliott
>
> Quick questions:
>
> a) Would those Fairhair devices ever be transit nodes ("routers") in the
>network itself ? Or even when only being leafs of the topology,
>would they intend to run RPL ?
TBD, I think.
>
> b) Any specific way how these devices get their IP (IPv6 ?) addresses ?
There will be multiple models in play, based on the operational
environment. In some cases, 802.15.4 networks will be used, in others,
wired, in some cases WiFi. Likely devices will start out with IPv4 and
require DHCP, and then in IPv6 both SLAAC and DHCP will be required.
But this is my personal view.
Eliot
signature.asc
Description: OpenPGP digital signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] CoAP et al
Thanks, Eliott
Quick questions:
a) Would those Fairhair devices ever be transit nodes ("routers") in the
network itself ? Or even when only being leafs of the topology,
would they intend to run RPL ?
b) Any specific way how these devices get their IP (IPv6 ?) addresses ?
I am wondering, because i wonder how much more anima than bootstrap could
be applicable to Fairhair devices.
Cheers
Toerless
In-Reply-To: <4108581b-d6b8-b284-eb26-d3c047372...@cisco.com>
On Wed, Aug 03, 2016 at 03:55:36PM +0200, Eliot Lear wrote:
> 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
--
---
Toerless Eckert, eck...@cisco.com
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] CoAP et al
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. 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. 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 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: +3486501 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
Re: [Anima] CoAP et al
Thanks, Rafa The combination of CoAP and EAP is certainly interesting. Let me quickly summarize how in ANIMA we got to not consider EAP when we looked at it without CoAP in the picture: 1. We did earlier in Anima investigate if/how we could/should use EAP to perform ANIMA bootstrap. It turned out that transporting all the desired key-infrastructure bootstrap messages across EAP would have been quite cumbersome. It would have been necesssary to use eg: EAP-TTLS which seems not to have seen wider use, and which would have required to much around with the client side TLS stack (those where the salient points if memory serves me right on this discussion). 2. Likewise, it seemed more appropriate for us to rely simply on IPv6 link-local addressing to first exist on clients than to figure out how to make sure L2-only solutions like EAPoL exist everywhere and would work across all L2 media - and having to tie ANIMA code into such L2 code. I can see how different industry groups that specifically work only with one particular L2 technology are happy to base more design on direct L2 layered protocols, but for ANIMA trying to be easily applicable across any L2 technology, IPv6-LL seemed like the best first approach. If specific L2 technologies have reasons not to use it, i think we could add-on optimizations for those link technologies. Cheers Toerless 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 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: +3486501 Fax: +34868884151 e-mail: r...@um.es > --- > > > > > ___ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] CoAP et al
Let's be clear about the Anima context for "bootstrapping". You don't have to look beyond the document abstract: " This document specifies automated bootstrapping of a remote secure key infrastructure (BRSKI) using vendor installed IEEE 802.1AR manufacturing installed certificates, in combination with a vendor based service on the Internet." Obviously it's assumed that there is some kind of *insecure* connectivity first. Which obviously implies a preceding insecure bootstrap of some kind, but that is not the topic. And, repeating myself I think, Anima is primarily aimed at nodes that manage devices, not at the devices themselves. However, we'd like BRSKI to be available to all devices, hence Max wrote draft-pritikin-coap-bootstrap. Again, please read the abstract: " This document provides an initial discussion of Bootstrapping of Remote Secure key infrastructures (BRSKI) when the device being bootstrapped speaks CoAP." Regards Brian On 16/08/2016 11:58, Rafa Marin Lopez wrote: > Hi Behcet: > >> El 15 ago 2016, a las 18:18, Behcet Sarikaya >> escribió: >> >> Hi Rafa, >> >> On Sun, Aug 14, 2016 at 7:05 AM, 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 >>> >> >> >> Thanks for your work. > > [Rafa] Thanks for your comments. >> >> One thing I would like to clarify: >> IoT bootstrapping should be done before the device gets an IP address. > > [Rafa] As you may know IPv6 link-local address may be used. I may agree with > your statement in a “global” or “routable" IP address. But, I guess, it will > depend on the scenario. In any case, I think we should first agree in what > IoT bootstrapping means and what are the requirements (MAY, MUST, SHOULD, …) > >> I think that CoAP works over IP, i.e.e the device already has been >> assigned an IP address. > > [Rafa] CoAP is being considered to be transported over the link-layer > directly (e.g. draft-bormann-6lo-coap-802-15-ie-00 or > draft-wang-6tisch-6top-coapie-01). Another example in LP-WAN > (draft-pelov-core-cosol-01) > > Btw there are also other protocols working on top of UDP (as CoAP) considered > to be transported directly over the link-layer (e.g. IKEv2) as you may know. > >> >> So whatever you do can not be called bootstrapping maybe something >> else which is security related, maybe some application layer key >> establishment. > > [Rafa] For the reasons mentioned above, I still call it bootstrapping > > Best Regards. > >> >> Regards, >> >> Behcet >>> Comments are welcome. >>> >>> Best Regards. >>> El 3 ago 2016, a las 15:55, Eliot Lear 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: +3486501 Fax: +34868884151 e-mail: r...@um.es >>> --- >>> >>> >>> >>> >>> ___ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >> >> ___ >> 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: +3486501 Fax: +34868884151 e-mail: r...@um.es > --- > > > > > _
Re: [Anima] CoAP et al
Hi Behcet: > El 15 ago 2016, a las 18:18, Behcet Sarikaya > escribió: > > Hi Rafa, > > On Sun, Aug 14, 2016 at 7:05 AM, 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 >> > > > Thanks for your work. [Rafa] Thanks for your comments. > > One thing I would like to clarify: > IoT bootstrapping should be done before the device gets an IP address. [Rafa] As you may know IPv6 link-local address may be used. I may agree with your statement in a “global” or “routable" IP address. But, I guess, it will depend on the scenario. In any case, I think we should first agree in what IoT bootstrapping means and what are the requirements (MAY, MUST, SHOULD, …) > I think that CoAP works over IP, i.e.e the device already has been > assigned an IP address. [Rafa] CoAP is being considered to be transported over the link-layer directly (e.g. draft-bormann-6lo-coap-802-15-ie-00 or draft-wang-6tisch-6top-coapie-01). Another example in LP-WAN (draft-pelov-core-cosol-01) Btw there are also other protocols working on top of UDP (as CoAP) considered to be transported directly over the link-layer (e.g. IKEv2) as you may know. > > So whatever you do can not be called bootstrapping maybe something > else which is security related, maybe some application layer key > establishment. [Rafa] For the reasons mentioned above, I still call it bootstrapping Best Regards. > > Regards, > > Behcet >> Comments are welcome. >> >> Best Regards. >> >>> El 3 ago 2016, a las 15:55, Eliot Lear 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: +3486501 Fax: +34868884151 e-mail: r...@um.es >> --- >> >> >> >> >> ___ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > > ___ > 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: +3486501 Fax: +34868884151 e-mail: r...@um.es --- ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] CoAP et al
Hi Rafa, On Sun, Aug 14, 2016 at 7:05 AM, 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 > Thanks for your work. One thing I would like to clarify: IoT bootstrapping should be done before the device gets an IP address. I think that CoAP works over IP, i.e.e the device already has been assigned an IP address. So whatever you do can not be called bootstrapping maybe something else which is security related, maybe some application layer key establishment. Regards, Behcet > Comments are welcome. > > Best Regards. > >> El 3 ago 2016, a las 15:55, Eliot Lear 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: +3486501 Fax: +34868884151 e-mail: r...@um.es > --- > > > > > ___ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] CoAP et al
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 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: +3486501 Fax: +34868884151 e-mail: r...@um.es --- ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] CoAP et al
I assume people have looked at draft-pritikin-coap-bootstrap. I don't see any discrepancy between that and Eliot's message. Brian On 04/08/2016 04:33, Michael Richardson wrote: > > Joel M. Halpern wrote: > > As I understqnd it, low power devices are usually viewed as having > limited > > capabilities. > > Thus, I would normally expect to see their autonomic functions handled > > by a > > proxy, much as a COAP gateway provides connectivity to the rest of the > > Internet for such devices. > > > If that is the case, then I would not expect to run GRASP or ANIMA > > bootstrap on the low end devices, but rather on the proxy. > > The goal is not to run GRASP or ACP on the low-end devices (the lightbulbs), > but rather to be able to use common infrastructure for bootstrapping. > > > What am I missing? > > It's not about running GRASP over an ACP between lightbulbs, it's about > enrollment/bootstrap. It might be about running GRASP over an ACP > between lighting controllers, and that may well involve the proxies you > mention. > > (It's also worth making a comparison to what we consider "limited > capabilities" to what we had as control plane CPUs 20 years years ago) > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > ___ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] CoAP et al
Joel M. Halpern wrote: > As I understqnd it, low power devices are usually viewed as having limited > capabilities. > Thus, I would normally expect to see their autonomic functions handled > by a > proxy, much as a COAP gateway provides connectivity to the rest of the > Internet for such devices. > If that is the case, then I would not expect to run GRASP or ANIMA > bootstrap on the low end devices, but rather on the proxy. The goal is not to run GRASP or ACP on the low-end devices (the lightbulbs), but rather to be able to use common infrastructure for bootstrapping. > What am I missing? It's not about running GRASP over an ACP between lightbulbs, it's about enrollment/bootstrap. It might be about running GRASP over an ACP between lighting controllers, and that may well involve the proxies you mention. (It's also worth making a comparison to what we consider "limited capabilities" to what we had as control plane CPUs 20 years years ago) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] CoAP et al
That is interesting and helpful. It does bring us to the problem of what we should require as mandatory to implement. But that can wait while we work out what the important cases are. Yours, Joel On 8/3/16 10:41 AM, Paul Duffy wrote: This is not just a constrained device issue. Open Connectivity Foundation is also using CoAP across a wide range of platform capabilities. On 8/3/2016 10:14 AM, Joel M. Halpern wrote: COuld any of the folks involved with low power answer one question this note suggests? As I understqnd it, low power devices are usually viewed as having limited capabilities. Thus, I would normally expect to see their autonomic functions handled by a proxy, much as a COAP gateway provides connectivity to the rest of the Internet for such devices. If that is the case, then I would not expect to run GRASP or ANIMA bootstrap on the low end devices, but rather on the proxy. I would instead expect a more specialized protocol (presumabvly over CoAP) for the last leg. Without ANIMA discovery, etc. What am I missing? Yours, Joel On 8/3/16 9:55 AM, Eliot Lear wrote: 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 ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima . ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] CoAP et al
This is not just a constrained device issue. Open Connectivity Foundation is also using CoAP across a wide range of platform capabilities. On 8/3/2016 10:14 AM, Joel M. Halpern wrote: COuld any of the folks involved with low power answer one question this note suggests? As I understqnd it, low power devices are usually viewed as having limited capabilities. Thus, I would normally expect to see their autonomic functions handled by a proxy, much as a COAP gateway provides connectivity to the rest of the Internet for such devices. If that is the case, then I would not expect to run GRASP or ANIMA bootstrap on the low end devices, but rather on the proxy. I would instead expect a more specialized protocol (presumabvly over CoAP) for the last leg. Without ANIMA discovery, etc. What am I missing? Yours, Joel On 8/3/16 9:55 AM, Eliot Lear wrote: 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 ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima . ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] CoAP et al
Hi Joel, There are many scenarios with low power devices that depend on their application area. Life for homenet devices is very different from life of devices in a well structured lighting installation. In the latter case, the devices will follow one industry standard to provide interoperability between devices. This standard can include many IETF standards. I will expect that the devices in the installation will follow their own favored discovery mechanism. Therefore, in their context the discovery is not essential. The bootstrapping protocol after discovery can be adhered to, although none of the recommended discovery mechanisms were followed. However, in the home context, or campus context, I can imagine that mDNS is important. Hope this answers your question, Peter Joel M. Halpern schreef op 2016-08-03 16:14: COuld any of the folks involved with low power answer one question this note suggests? As I understqnd it, low power devices are usually viewed as having limited capabilities. Thus, I would normally expect to see their autonomic functions handled by a proxy, much as a COAP gateway provides connectivity to the rest of the Internet for such devices. If that is the case, then I would not expect to run GRASP or ANIMA bootstrap on the low end devices, but rather on the proxy. I would instead expect a more specialized protocol (presumabvly over CoAP) for the last leg. Without ANIMA discovery, etc. What am I missing? Yours, Joel On 8/3/16 9:55 AM, Eliot Lear wrote: 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 ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] CoAP et al
COuld any of the folks involved with low power answer one question this note suggests? As I understqnd it, low power devices are usually viewed as having limited capabilities. Thus, I would normally expect to see their autonomic functions handled by a proxy, much as a COAP gateway provides connectivity to the rest of the Internet for such devices. If that is the case, then I would not expect to run GRASP or ANIMA bootstrap on the low end devices, but rather on the proxy. I would instead expect a more specialized protocol (presumabvly over CoAP) for the last leg. Without ANIMA discovery, etc. What am I missing? Yours, Joel On 8/3/16 9:55 AM, Eliot Lear wrote: 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 ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
