Yes I was only stating that establishing a root of trust for device authentication seems to work - as Brian said, authorization is a different thing. However, authorization might be assisted by an existing trust relationship for identity.
Randy Sent from my Verizon Wireless 4G LTE smartphone -------- Original message -------- From: "STARK, BARBARA H" <[email protected]> Date:09/18/2014 5:02 PM (GMT-06:00) To: Randy Turner <[email protected]>, Michael Thomas <[email protected]>, [email protected] Cc: Subject: RE: [homenet] HNCP security? > How do you bootstrap trust relationships without an initial certificate > (whether installed at manufacturing or during a customer fulfillment stage) ? There's a difference between trusting (authenticating) a device when it says "this is my key; whenever you see this key you can trust that it's me and no-one else" and trusting (authorizing) a device to perform a particular role of, e.g., "a user-approved router in the user's home network". If the device signs its own key, you can usually trust that it is itself. But I do believe that providing authorization requires user configuration. If the user is unwilling to participate in providing authorization, then the user is choosing to run HNCP unsecured. It should be possible to run HNCP unsecured with zero configuration (just as with the powerline adaptors it was possible to set up the network without pushing the buttons). But if the user wants security, then the user has to be involved. Even if it's just to push a button on 2 devices within a 2 minute window (which on most "no new wires" PHY layer devices effectively authorizes the device to participate in the network). I really see no way to enable security without some user involvement. And as long as the user has the choice to run without security, I see no problem in requiring it. Barbara -------- Original message -------- From: Michael Thomas <[email protected]> Date:09/18/2014 4:17 PM (GMT-06:00) To: [email protected] Cc: Subject: Re: [homenet] HNCP security? On 9/18/14, 2:10 PM, STARK, BARBARA H 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. Yes, I agree and that's why self-signed and/or manufacturer certs are of no help. There is no believable authz in them. A homenet would need to run its own CA, or use a CA that it delegates authz to. Or does something that avoids certs altogether and provides its own enrollment/authz solution. Mike _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
