This all seems reasonable. I think I understand this better and I really appreciate people being willing to talk it through.
>From my perspective it would be nice if we added a bit more text to the document to explain this stuff. Would people be interested in that? Would they want me to produce text? -Ekr On Thu, Dec 14, 2017 at 9:15 AM, Max Pritikin (pritikin) <priti...@cisco.com > wrote: > > On Dec 14, 2017, at 9:32 AM, Eric Rescorla <e...@rtfm.com> wrote: > > > > On Thu, Dec 14, 2017 at 8:29 AM, Max Pritikin (pritikin) < > priti...@cisco.com> wrote: > >> >> On Dec 14, 2017, at 8:43 AM, Eric Rescorla <e...@rtfm.com> wrote: >> >> >> >> On Thu, Dec 14, 2017 at 7:40 AM, Michael Richardson < >> mcr+i...@sandelman.ca> wrote: >> >>> >>> Eric Rescorla <e...@rtfm.com> wrote: >>> > The case I am concerned with right now is the case where the >>> attacker >>> > just imprints the device and then operates it even though it's in >>> the >>> > victim's network. >>> >>> How can they join the victim's network, if the point of the enrollment >>> is to >>> provide the device with keys to be able to join the victim's network? >>> >> >> Ah, now I think we're getting somewhere. I had understood the point of >> the enrollment in this context to be to get it to join the ANIMA fabric, >> not necessarily the physical network (hence why we have ACP, etc.) >> >> Am I just totally missing the point here? >> >> >> So, more directly responding to your concern: What happens if the >> attacker “just imprints the device and then operates it even though its in >> the victim’s network”? >> Answer: >> >> If the vendor system has sales channel integration then the voucher >> signatures provide an optional method of blocking “attacker imprint” >> (because it is no longer trust-on-first-use). This PREVENTS the attack >> you’re asking about. >> If the victim network operator has appropriate inventory management then >> BRSKI/MASA integration provides logging inputs into that system to DETECT >> the scenario you describe, even without sales channel integration. >> > > So if neither of these cases applies, then the attack succeeds? > > > Correct. My preference is the non-sales channel approach where the network > operator has complete control. > > To be clear, I'm not saying this is a defect in the protocol. I don't know > how to fix it. I'm just trying to get clear. > > > Agreed. I don’t see this as a “defect” myself, its a conscious decision to > allow flexibility in deployment models. > > This is important because secure bootstrapping requires devices to engage > in security operations. Doing so runs the risk that something won’t work > when needed. Our design choice is to limit the device security operations > to the minimal amount: just sufficient for network operator audit or vendor > control. This should be more reliably while allowing the the vendor or the > network operator can provide substantial security *if they want*. > > - max > > > -Ekr > > >> >> Once detected, then what? The BRSKI draft has this to say about its >> protocol flow and network access control: >> >> draft-ietf-anima-bootstrapping-keyinfra-09: >> >> This document presumes that network access control has either already >> occurred, is not required, or is integrated by the proxy and >> registrar in such a way that the device itself does not need to be >> aware of the details. Although the use of an X.509 Initial Device >> Identity is consistant with IEEE 802.1AR [IDevID >> <https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-09#ref-IDevID>], >> and allows for >> alignment with 802.1X network access control methods, its use here is >> for Pledge authentication rather than network access control. >> Integrating this protocol with network access control, perhaps as an >> Extensible Authentication Protocol (EAP) method (see [RFC3748 >> <https://tools.ietf.org/html/rfc3748>]), is >> out-of-scope. >> >> Its even more out of scope for the voucher itself since that is a msg >> format for “who should the device trust” and to trigger enrollment but is >> even further removed from network access control. >> >> A potential integration is to use ANIMA or BRSKI to manage device >> enrollment and credential from a quarantine network. The network access >> control could be configured to segregate all devices that are not enrolled >> (perhaps into a true quarantine network or maybe just pass them all through >> to a carefully managed dmz or … whatever). If the device enrolls >> successfully then you get on the “real” network. In your scenario then the >> attacker gain control over a device that is untrusted and placed >> appropriately by the network access control system. But as noted, providing >> the tools for this is different than actually defining that integration. I >> encourage the network access control folks to address these types of >> concerns. >> >> - max >> >> >> -Ekr >> >> >>> >>> (The exact nature of the keys depends upon how the voucher is used. >>> In BRSKI it's to bootstrap an EST connection, while in some versions of >>> the >>> 6tisch, actual 802.15.4 keys are return. NETCONF uses this new trust to >>> permit the owner to reach in and do configuration with RESTCONF) >>> >>> -- >>> Michael Richardson <mcr+i...@sandelman.ca>, 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
