And all of this was covered in the design for UPnP Device Protection that you referred to earlier and its progenitor UPnP Device Security. I consider HNCP security to be a small subset of the UPnP device requirements.
Mark On Sep 18, 2014, at 2:10 PM, STARK, BARBARA H <bs7...@att.com> wrote: >> Self-signed certs bring only confusion, IMO: they are nothing more than a >> raw key with an unsubstantiated claim to another name, along with a whole >> lot more ASN.1 baggage beyond what is needed to parse the modulo and >> exponent. >> >> And you don't get usage or policy restrictions without a CA that the >> *HOMENET* trusts to assert them, nor can that sort of policy assertion be >> done with device certs since I don't have any reason to believe >> fly-by-night's >> routers should be allowed to do whatever it is they claim they want to do. > > No, this would only be true if there were an implied authorization to go > along with the authentication. That's why it's so important for the user to > have to take an initial step of providing authorization (in the event where > the user has chosen to secure homenet -- of course the use should have the > option not to force homenet to run securely, just like the user can choose to > run Wi-Fi without security or not to push the buttons on powerline networking > devices [distinct from the buttons on Wi-Fi devices] in order to create a > secure powerline network). > > Since the user should be responsible for providing authorization, and > authentication should be completely separated from authorization, the key is > *only* for authentication. The key would only need to be revoked if it were > believed that some other device were using the key (the key to device > association could no longer be trusted). Revoking authorization is done by > changing the role that a device using the key is allowed to perform. The user > should be able to do this. And then the same mechanism used to provide new > devices with the key/role list can be used to supply all devices with the > updated key/role list. > > If a key is associated with a "guest" role, it shouldn't be necessary to > delete that entry in the key/role list unless the user really wants to make > sure that the device is not allowed to come back again as a guest. A user who > cares to should be able to edit the key/role list whenever they like > (including deleting entries). But a user who does not choose to ever edit the > list when there is no evidence of a problem would be fine. A "friendly name" > is important. But that's becoming important to so many things in the home > network. > Barbara > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
