> On 25 Jun 2019, at 21:52, Michael Richardson <[email protected]> wrote: > > Signed PGP part > > Eliot Lear <[email protected]> wrote: >> A few of us are just trying to put out an initial draft that addresses >> one gap in MUD (there are several). > >> In a MUD file one can say that one >> wants to access a controller in two ways: either "my-controller” >> meaning a controller that services devices of a particular MUD URL or a >> “controller” class that services devices based on a particular class >> name of controller. > > I think that we have two potential avenues for security attacks here: > 1) a device that claims to be a controller in order to gain access to > devices. > 2) devices that claim to be belong to a controller in order to attack > controllers. > > To my mind there are some different things we could do: > > 1) insist that to user the my-controller connections that the two devices > have to be signed by the "same" entity. ["same" could mean literal the > same key, the same certificate Issuer/DN, or something more complex] > > 2) we could have devices declare in an MUD extension the > DN/certificate/entity which must sign their controller device. > > 3) (2) above, but with some level of indirection through some URL.
I could see these as options. > >> In either case, right now the administrator has to manually know and >> populate information, to say - some device 1.2.3.4 is a controller, >> either for MUD URL https://example.com/mud <https://example.com/mud> or >> a class http://example.com/mudclass1 <http://example.com/mudclass1>. >> That can be laborious. To assist, we are examining ways to have a >> controller declare itself as a candidate controller. That at least >> provides a hint to the administrator that this particular device is >> capable of serving in a particular role. > > I think that anything that requires administrator activity to be a fail for > residential use. It's too complex. There will ALWAYS be a need for an administrator in the enterprise case. But maybe with the options above we can ease the consumer burden over time. In the consumer case, you might want an app for initial device admission control anyway, no? Can we not rely on that interaction as an approval step in this instance? > >> To make that declaration, the device must- Form the declaration; Find >> the MUD manager; and Send it. > >> Finding the MUD manager depends on one question: Was the device built >> to be a controller or is it a general purpose device that has an app >> that is intended to be a controller? > >> If the device was built to be a controller, we can simply cram the >> declaration into that devices own MUD file as an extension. If the >> device is a general purpose computer, things get a bit more >> interesting. > > Yes... but I think that we have to solve the multi-purpose computer MUD > anyway. The intelligent speakers (Echo,Home,Mycroft,etc.) need to gain new > MUD definitions as they gain "skills", and I think that we can treat a > smartphone in a similar way. > > This might be a place where IPv6 wins, if we can split off each skill into a > new provisioning domain, giving it a new IPv6 IID. I was thinking that maybe > we can associate the private key that signed the MUD file to the IID via > something like SEND/CGA, but I'm not sure how many private keys we have > (one for the app developer, or one per app installed on each device). > >> In this case we have two choices: > >> Either create a MUD file that points somewhere internally - this >> doesn’t seem very plug and play. Make the declaration directly to the >> MUD manager. > >> I’m going to focus on the latter for the moment. It is easy enough to >> create a RESTful interface for this purpose, but it requires a >> mechanism to discovered the MUD manager, which up until now has been an >> internal part of the network infrastructure. > >> Let me call this out plainly: letting the app itself directly call the >> MUD manager requires that the MUD manager itself become exposed to the >> user infrastructure, which is a change. > > Agreed. > And that the MUD manager have some reason to trust the device is not p0wned, > and sending a bogus MUD file up. A certificate chain back to the > manufacturer is not enough, it has to be signed by a key that an attacker > can't get access to. So that requires attested keys if they are "local", or > for the signature to be done elsewhere. > >> One possibility to address this is to incorporate the new RESTful >> endpoint into an ANIMA BRSKI join registrar, which may already be >> exposed. But that requires that ANIMA BRSKI be in play, which it may >> not. > > It is, however, a really good idea for the case where it is in play. > >> My thinking is that we do this work in two stages. First handle the >> easy case, which is the MUD file extension, and then figure out how to >> do the app version of this. > >> Thoughts? > > yes. > Was that “yes” to the two stage approach? Eliot > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
