Anoop Kumar Pandey <an...@cdac.in> wrote: > So JRS has all legitimate manufacturers and is procuring pledges from > known sources (out of these legitimate manufacturers), then where is > the hostility?
There are hostile devices on the network, and there are hostile networks that might attempt to take over the pledge. The IDevID protects the network against hostile pledges, and the voucher protects the pledge against hostile networks. There is also the non-malicious situatoin where a pledge simply has multiple (usually wireless!) networks to which it may join. The voucher lets the pledge decide which network will have it. However, we haven't decided how to do this for 802.11; in 6tisch we are doing this for 802.15.4. > That’s what I was trying to say in my initial mail that given an > unknown MI or a collaboration between pledge and MI, can security be > established using Automated BRSKI? If your network's policy is to accept devices from unknown MIs, and the MI is willing to issue vouchers to unknown domains, then you can be sure that the connection is good. By definition the pledge, being built by the MI, is *always* in collaboration with it. In ANIMA we do not go into home user situations, but that's due to charter restrictions, not technology. We do think that BRSKI can be used to bootstrap Homenet. In that situation, one can imagine buying lightbulbs From Home Depot, and bring them home. A JRC could run on a phone (or more likely an app that speaks to a JRC via an API). Unknown MIs might be accepted, but why do that when a QR code could be scanned by the phone to introduce the MI. > Also the pledge trusts JRC if JRC is able to pass on the voucher from > MASA to pledge. MASA only checks JRC’s certificate. Therefore any JRC > having a valid certificate may pass on the voucher from MASA to pledge > and become owner of the pledge [case of theft]. Yes, that's the case if the manufacturer does not know (or care) who bought what. That's reasonable for quite a number of cases. Routers are usually spared by manufacturers by geography, and given <4hr replacement SLAs, there just isn't time on a Sunday morning at 4am to do any sales paperwork. What might matter is that the JRC is *a* customer, but it doesn't matter which. {Such a thing would have really helped me out in quite a number of times, as I would get woken up at 5am, when the field operative guys can't figure out why the router with the "export" firmware won't run securely, because it needs the "cryptographic" firmware, but that license key is not valid for that device} > I believe, BRSKI is a one-time imprinting service to a domain through > JRC. Once that is done, any unauthorized access (depending on the > vulnerability in the pledge) post EST, may not be stopped. That's true. That's not entirely our problem; we do however, by providing the pledge with an LDevID and certificate trust anchors via EST, support doing very secure authorization processes later on. No default passwords, etc. because no passwords are needed if both ends have certificates they can use. > BRSKI, is it one time process? > Or during each access to device will it re-run? One time process. > When do we require to re-run this, only on domain-transfer? On resale, the device should be put through a factory reset to clear things. The MASA will have to be willing to issue a new voucher to the new domain owner. > Does it happen automatically whenever a device enters a domain or can > it started deliberately? It is not automatic. It needs to be deliberate. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima