Re: [homenet] security question for zeroconf stuff inside the homenet...
On 10/19/2011 12:30 PM, Curtis Villamizar wrote: In message28269.1318994...@marajade.sandelman.ca Michael Richardson writes: Curtis == Curtis Villamizarcur...@occnc.com writes: Curtis A WiFi AP will not connect to another AP and wireless Curtis routers are typically AP by default. So if two wireless Curtis routers autoconfig to being AP and using open routing, then OUT OF THE BOX: not every device plugged into a home network have no prior configuration. For instance, someone bringing a newsed device to grandma's house. He who configures it needs to fix it. Or press the factory default button (if there is one). The example is two AP. Most AP can be restored to factory default with a button press. What happens if you have two of them and they're BOTH configured to boot as the master home access point? ... Curtis there is only a risk if something that is an WiFi client is Curtis also a configured to be a router. Yes, but we want to assume that at least one of these will be configured as a router as a default, which means we KNOW someone will turn on two of them On BSD and I suspect Linux as well, the default for: net.inet.ip.forwarding net.inet6.ip6.forwarding are both zero. Right, but that cannot be the default for a homenet box. Joe ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
In message 4e9f3e69.90...@isi.edu Joe Touch writes: On 10/19/2011 12:30 PM, Curtis Villamizar wrote: In message28269.1318994...@marajade.sandelman.ca Michael Richardson writes: Curtis == Curtis Villamizarcur...@occnc.com writes: Curtis A WiFi AP will not connect to another AP and wireless Curtis routers are typically AP by default. So if two wireless Curtis routers autoconfig to being AP and using open routing, then OUT OF THE BOX: not every device plugged into a home network have no prior configuration. For instance, someone bringing a newsed device to grandma's house. He who configures it needs to fix it. Or press the factory default button (if there is one). The example is two AP. Most AP can be restored to factory default with a button press. What happens if you have two of them and they're BOTH configured to boot as the master home access point? Master home access point? What is that? We are not talking about today's primitive NAT boxes that pretend to be routers. They either have a default route to the Internet or they don't. If they have a defailt route and they are at equal distance to that default route, then there are some arbitrary tie breakers. Worst case for AP might be if they are hard configed to the same channel and are very close to each other so they have about the same S/N and hosts can't decide which one to associate with, plus the interference with each other. In any case a press of the factory settings button should fix it. ... Curtis there is only a risk if something that is an WiFi client is Curtis also a configured to be a router. Yes, but we want to assume that at least one of these will be configured as a router as a default, which means we KNOW someone will turn on two of them We want to assume that *all* AP are configured as routers except the legacy ones that want to be a dumb bridge with NAT to one port. On BSD and I suspect Linux as well, the default for: net.inet.ip.forwarding net.inet6.ip6.forwarding are both zero. Right, but that cannot be the default for a homenet box. You are mixing the discussion of what we want in routers with what we don't want enabled by default in every *legacy* PC, toaster and coffee maker. If the coffee maker is a competent IPv6 router with extensions to let it autoconfig, then let it be a router. I really don't want my dumb old kitchen appliances trying to NAT for each other. But that new IPv6 espresso maker that knows how to act as a router - that would be OK. :-) You lost the context. You snipped out the statement I was replying to. A little too much trimming on the response. It happens. Joe Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
Curtis == Curtis Villamizar cur...@occnc.com writes: Curtis A WiFi AP will not connect to another AP and wireless Curtis routers are typically AP by default. So if two wireless Curtis routers autoconfig to being AP and using open routing, then OUT OF THE BOX: not every device plugged into a home network have no prior configuration. For instance, someone bringing a newsed device to grandma's house. Curtis there is only a risk if something that is an WiFi client is Curtis also a configured to be a router. laptop, smartphone, wii, stereo mp3 player, ... -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
Should the applications be insecure and rely on a firewall? (Microsoft advocated this in the 1990s and it has stuck to a large extent). Or should the network be open and the applications secure? I'm strongly with you on this. The applications should take care of any security that is necessary *for that application*. In other words, we should abandon door locks and make certain that anything you don't want stolen is individually secured --because only the device manufacturer could ever know how valuable it is, and how best to prevent it being stolen? In your own words: No. No. No. Security is layered in the physical world, and it should be layered in the network, as well. That I argue for a default domain based posture, where all machines within a given domain are all fully reachable, but those outside the domain are not reachable unless specific actions are taken to make them reachable, doesn't mean I don't think individual computers need security at all, or that all security should rely on the firewall. All security must be on the firewall or in the applications is a false dichotomy. Security is not a layer-2 function. Security is an application function. You had it right the first time. Key exchanges and certificates are not layer-2 functions. Security is an application function, yes. Security is also a network function, and security is a machine level function. All of these have a role to play in security. :-) Russ It is entirely possible that the same computer has pictures of Grandma that I'm OK with you seeing and has a printer hanging off it that I don't want anyone in the world to be able to print on. Same MAC address. So that can't be a layer-2 function. And port filtering at a firewall is a lame excuse for security. The bug in relying on a firewall in an enterprise (a little less so for a home) is that once any one user downloads malware, that malware has access to everthing behind the firewall largely because of the assumption that security is not needed because there is a firewall. Lets not enshine the dumbest practices of the IT world. I think homenet should focus on L3. (and be clear on what it expects from the other layers with regards to security). cheers, Ole Curtis ___ 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
Re: [homenet] security question for zeroconf stuff inside the homenet...
In message 8031f94c-66bf-4748-aa97-5efa12bb8...@fugue.com Ted Lemon writes: If you autoconfigure a routing topology, you have to make sure that you don't accidentally autoconfigure it to include routers that weren't intended to have been included. The concern is not for grandma running Windows 98, and the whole hard shell/gooey center debate is completely beside the point. You've said what the problem *isn't*, so what *is* the problem on a homenet? Surely the provider is not going to accept a unauthenticated auto-config hello request and start peering, nor will it accept a hello from a legacy router configured with router-id and a be adjacent to anything policy. If the electric meter wants to be a router with a slow link on the power line, then it needs to act like a provider router, but perhaps only advertising reachability to the electric utility, not the whole Internet. The more specific prefix (than default) should get the attention of the water heater if it has to try to reach the electric utility. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
On Oct 13, 2011, at 2:35 PM, Curtis Villamizar wrote: You've said what the problem *isn't*, so what *is* the problem on a homenet? I did say what the problem is: If you autoconfigure a routing topology, you have to make sure that you don't accidentally autoconfigure it to include routers that weren't intended to have been included. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
In message 4e96ce51.7020...@riw.us Russ White writes: Should the applications be insecure and rely on a firewall? (Microsoft advocated this in the 1990s and it has stuck to a large extent). Or should the network be open and the applications secure? I'm strongly with you on this. The applications should take care of any security that is necessary *for that application*. In other words, we should abandon door locks and make certain that anything you don't want stolen is individually secured --because only the device manufacturer could ever know how valuable it is, and how best to prevent it being stolen? Following that analogy, the door locks built my certain OS vendors are both flimsy and easily picked. And we should not enable tftp and point it at the root directory and hope that some smart network appliance will somehow firewall us. In your own words: No. No. No. Security is layered in the physical world, and it should be layered in the network, as well. That I argue for a default domain based posture, where all machines within a given domain are all fully reachable, but those outside the domain are not reachable unless specific actions are taken to make them reachable, doesn't mean I don't think individual computers need security at all, or that all security should rely on the firewall. All security must be on the firewall or in the applications is a false dichotomy. Ideally the firewall should be unnecessary. In some cases a firewall is out of the question. For example, a router cannot rely on sitting behind a firewall. That is not to say that packet filters at the border don't serve as a valuable denial of service protection against pure traffic based attacks. Firewalls more often get in the way than do any good. They also give a false sense of security which results in the occasional our LAN is currently swamped as a result of the latest virus run amuck on our LAN coming from IT. Security is not a layer-2 function. Security is an application function. You had it right the first time. Key exchanges and certificates are not layer-2 functions. Security is an application function, yes. Security is also a network function, and security is a machine level function. All of these have a role to play in security. :-) Russ The operations staff for the T3-NSFNET had no firewall and was security audited by some of the best in the field. Of course we did not allow the use of a PC with Windows in operations. No such thing could sit on the same subnet. Another division in ANS that relied on a firewall was the only part of the company that even had to have all computers taken down and scrubbed before they could be used again. [Requirement at that time of having certain government customers]. Every computer had to be physically removed, rebooted from other media, backed up, reinstalled, user files restored from a backup prior to the breach, and returned to the rack or the user's desk. Users had to fetch any lost work from the backups and were supposed to insure that no changes where made to recovered source code. Sound painful and costly? It was! Network protection of insecure host applications is false security. It takes just one host breach to compromise the whole internal network. I've seen it first hand many times. [not quite first hand since my computers never relied on a firewall for security but a few times on the corporate LAN they were sitting on.] IPSEC also got it wrong. The application really is the right place for security. :-) btw- Anti-virus software is a cruel hoax. [that someone makes money on] :-) It is entirely possible that the same computer has pictures of Grandma that I'm OK with you seeing and has a printer hanging off it that I don't want anyone in the world to be able to print on. Same MAC address. So that can't be a layer-2 function. And port filtering at a firewall is a lame excuse for security. The bug in relying on a firewall in an enterprise (a little less so for a home) is that once any one user downloads malware, that malware has access to everthing behind the firewall largely because of the assumption that security is not needed because there is a firewall. Lets not enshine the dumbest practices of the IT world. I think homenet should focus on L3. (and be clear on what it expects from the other layers with regards to security). cheers, Ole Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
In message 7d42549b-0ec1-463e-8e62-765c295a2...@fugue.com Ted Lemon writes: On Oct 13, 2011, at 5:23 PM, Curtis Villamizar wrote: And I responded to that in the same email and you trimmed that part of the response in this email. The problem has to do with customer-owned devices and customer-neighbor-owned devices forming networks together. It's got nothing to do with the ISP. Chances are, the ISP link is the one thing that won't be gotten wrong here, because only one device you own will be connected to it (at least in typical networks today). And therefore risk there is mostly theft of service as I have already pointed out. A WiFi AP will not connect to another AP and wireless routers are typically AP by default. So if two wireless routers autoconfig to being AP and using open routing, then there is only a risk if something that is an WiFi client is also a configured to be a router. Of course, if your devices unintentionally include your neighbor in the home network topology, your network will suddenly be multihomed, but this is an artifact of the failure mode I'm talking about. Eliminating that failure mode would solve the multihoming problem as well. Some would call that a feature, not a failure mode. :-) But it usually does violate the service provider agreement and therefore open routing (or bridging) over wireless creates a potential theft of service. Ignoring that AP don't talk to AP. This is really an issue for wireless not for wired and is nothing new. AFAIK all wireless products today ship open and configured as an AP and have to be changed to enable some form of authentication. And many users never bother to change this. So what is new about a wireless router vs existing wireless bridges that do this? Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
On Oct 13, 2011, at 7:02 PM, Curtis Villamizar wrote: And therefore risk there is mostly theft of service as I have already pointed out. No, that is a side issue. The risk is that two networks will self-configure into a single topology without being told to do so. Some would call that a feature, not a failure mode. :-) Your optimism is charming. However, the more likely case is that the network topology that automatically forms will not work, or will direct all traffic out a single internet link and go over someone's service limits. And there will be nobody within shouting distance of this fiasco who will be qualified to even guess what might be happening, much less fix it. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
On Oct 13, 2011, at 9:13 PM, Lorenzo Colitti wrote: I'd say that electrical systems are as susceptible to rogue devices just as much as zeroconf routing systems are. If you plug a short into a socket, you trip a circuit breaker and you deny service to other appliances (i.e., your house goes dark). This is true, but I think I hear the sound of shrieking as you torture this poor analogy... :) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
2011/10/12 Joel jaeggli joe...@bogus.com On 10/11/11 18:38 , Ted Lemon wrote: On Oct 11, 2011, at 9:03 PM, Michael Richardson wrote: However, I am thinking that we can perhaps bootstrap equipment that has never been configured (or has been factory reset) in some fashion such that if the equipment is virginal that it can essentially always try some default keys, and bring up enough networking to let all equipment be discovered and identified. There would be strong nag screens to get the user to up a network password. A pre-shared key that is pre-shared to every device is the same as no key. Not really, it could serve an important hygenic function, notionaly, it could be filtered by default on all non-home-network gear. that is serves the purpose of identifying a well-known-service. there are of course other perhaps better ways to implment that. So you might as well not bother with that complexity. Conceivably CGA could be used to publish public/private key pairs allowing devices to automatically recognize each other and present their relationships in a UI for the end user to approve, but that's not precisely plug and play. I think the simplest thing would be to require that each device be able to talk to a USB drive. Each device collects all the public keys on the USB drive, and stores their own there. Devices then share their public key with other devices identified on the USB drive, so that as each device joins the network, the other devices learn about it. This isn't bulletproof—an infected PC that's configured with these keys could be used to gain access to the keys, for example. But it's a lot better than a well-known key. What about ID-based signature? Just improvising (so forgive me for any naivety): the ID of the device could be a triplet (producer-ID, product-ID, serial-number); the key generator could be the producer itself (avoiding in this way the key escrow problem related to ID-based cryptography) and a certificate with the public key of the producer could be downloadable from some well-known host (alternatively, the key of most known producers could be built in the device). The authentication procedure would follow the usual challenge scheme: the device receives a challenge string, it appends to it a nonce and signs the result with its private key (hardwired at production time). If the authentication is positive, then you know that you are talking to that type of device, produced by that producer (if you trust the producer is another matter). Of course, this simple scheme would fall to a device-in-the-middle attack, but maybe in this context it is not a likely attack. Of course, this isn't quite as plug and play as you seem to want, and it requires that each device have a USB port, which might not be acceptable. Plus, it would mean that the IETF would have to talk about hardware, which seems like a bit of a non-starter. But I think it's the right way to solve the problem. ___ 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
Ted, using the electricity network as an analogy, can we make a distinction between safety and security? the electricity network in the home is somewhat self protecting with breakers and earthing. a home network must protect 'itself', i.e. handle any device plugged into it, in any topology, external and internal attacks and so on. I am highly sympathetic to the desire not to try to solve this problem. However, unfortunately network topology isn't the same as electrical topology, for a couple of reasons. The first reason is that electrical systems are generally set up by professionals. Yes, you plug devices into the electrical wiring of your house, but someone skilled set it up (or if not, I hope you sleep in asbestos pajamas). The devices we are talking about are more analogous to circuit distribution panels than to toasters. The second reason is that electrical systems are essentially topology-free. Any point on the system is essentially equivalent to any other. This is not true of a home network with routing. What we are talking about is essentially the possibility of rogue distribution panels intentionally or accidentally being connected to your distribution system. Which is a result of the third reason: home networks are typically wireless, or partially wireless, and so there is no physical security, unlike an electrical network in a house, which is secure by virtue of being entirely enclosed by the house. I think what you are getting at is that we cannot be responsible for securing the network. And that is probably true. But if the system doesn't have a built-in mechanism for distinguishing between friend and stranger, the autoconfiguration mechanism will create topologies that aren't desired, either by accident or because a stranger wants access to the network. I do agree with that. I think we can figure out a way of pairing devices. whatever layer that ends up being done at. it will be much more difficult to protect against hostiles injecting default routes, or pretending to be DHCP servers and so on. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
On Oct 12, 2011, at 8:46 AM, Ole Troan wrote: I think we can figure out a way of pairing devices. whatever layer that ends up being done at. it will be much more difficult to protect against hostiles injecting default routes, or pretending to be DHCP servers and so on. I think pairing and general network security are largely the same problem. Of course if someone is granted access to the network, they can then inject routes or pretend to be a DHCP server, but that's not the issue I'm concerned with. I'm more concerned with the scenario Jim Gettys talked about in a subsequent message, where a bunch of things clump together and start talking to each other essentially accidentally. And of course I'm also somewhat concerned about attackers, although I think that's probably going to happen less often than accidental clumping. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
In message 4e94bf91.4060...@cs.tcd.ie Stephen Farrell writes: Hi, I've been reading the list with interest and have a question. When various devices in the home figure out which does what, and do that periodically to handle changes, there's clearly the potential that a zombied host tries to try take over stuff with undesirable consequences. My question is whether this group are planning to think about that now, or later, or never? (Or don't even think there's a problem worth attempting to address.) Note - I'm not trying to argue for any particular level of security and certainly not for some unachievable fort knox everywhere, I'm just asking what's the plan? S. Watch out for autoconfig of microphones and cameras. :-) I call it bonding. Some ritual has to be performed before specific types of devices trust each other. Like the garage door opener and the clicker thingie. Same should be true of the audio system and the wireless speakers. The TV and remote use IR. The routers just route, but they need to be a bit more picky about who can configure them. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
In message 159dbf45-107c-4c12-ae01-9bb494e8e...@fugue.com Ted Lemon writes: On Oct 11, 2011, at 9:03 PM, Michael Richardson wrote: However, I am thinking that we can perhaps bootstrap equipment that has never been configured (or has been factory reset) in some fashion such that if the equipment is virginal that it can essentially always try some default keys, and bring up enough networking to let all equipment be discovered and identified. There would be strong nag screens to get the user to up a network password. A pre-shared key that is pre-shared to every device is the same as no key. So you might as well not bother with that complexity. Conceivably CGA could be used to publish public/private key pairs allowing devices to automatically recognize each other and present their relationships in a UI for the end user to approve, but that's not precisely plug and play. Agree completely on this. For example, having bumping the factory default button on a wireless camera open access to everyone would really be a bad idea. I think the simplest thing would be to require that each device be able to talk to a USB drive. Each device collects all the public keys on the USB drive, and stores their own there. Devices then share their public key with other devices identified on the USB drive, so that as each device joins the network, the other devices learn about it. This isn't bulletproof=97an infected PC that's configured with these keys could be used to gain access to the keys, for example. But it's a lot better than a well-known key. Of course, this isn't quite as plug and play as you seem to want, and it requires that each device have a USB port, which might not be acceptable. Plus, it would mean that the IETF would have to talk about hardware, which seems like a bit of a non-starter. But I think it's the right way to solve the problem. Mandating USB is not practical. For example I have a set of DECT phones with a single SIP base station. You can bond the phone to the base station but you have to enter a menu on the phone and do something on the base station (through the web interface or otherwise) within 10 seconds. Not perfect, but it works. There are too many cases like bonding the garage door opener to the clicker, or bonding the speakers to the audio system, etc, don't need to store keys on a USB as a boot strap. For some things USB would be fine. And my water heater, as facinating as it might be to the electrical utility, need not have the key to my garage door opener or my audio speakers, even though I might want to turn the hot water up or down a few degrees through a remote device some day. I would say that reinventing the kerberos KDC with ticket granting tickets and service tickets is probably overkill and should be out of scope. But it would be a truly wonderful thing if the interface could be made simple enough for a consumer to set up. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
In message 78ce7d95-48c9-4de4-9707-f11ac2a05...@cisco.com Ole Troan writes: I've been reading the list with interest and have a question. When various devices in the home figure out which does what, and do that periodically to handle changes, there's clearly the potential that a zombied host tries to try take over stuff with undesirable consequences. My question is whether this group are planning to think about that now, or later, or never? (Or don't even think there's a problem worth attempting to address.) Note - I'm not trying to argue for any particular level of security and certainly not for some unachievable fort knox everywhere, I'm just asking what's the plan? can we explore some fundamental principles of how and what we need to secure? Yes. Please do. using the electricity network as an analogy, can we make a distinction between safety and security? the electricity network in the home is somewhat self protecting with breakers and earthing. a home network must protect 'itself', i.e. handle any device plugged into it, in any topology, external and internal attacks and so on. I don't think it is the networks job to control who has access to the pictures of my grandmother or who can print to my printer. that's application policy. Exactly. This is a multi-decade old debate. Should the applications be insecure and rely on a firewall? (Microsoft advocated this in the 1990s and it has stuck to a large extent). Or should the network be open and the applications secure? I'm strongly with you on this. The applications should take care of any security that is necessary *for that application*. is it the networks job to control who has access to the network? no, I think that is a layer 2 function. No. No. No. Security is not a layer-2 function. Security is an application function. You had it right the first time. Key exchanges and certificates are not layer-2 functions. It is entirely possible that the same computer has pictures of Grandma that I'm OK with you seeing and has a printer hanging off it that I don't want anyone in the world to be able to print on. Same MAC address. So that can't be a layer-2 function. And port filtering at a firewall is a lame excuse for security. The bug in relying on a firewall in an enterprise (a little less so for a home) is that once any one user downloads malware, that malware has access to everthing behind the firewall largely because of the assumption that security is not needed because there is a firewall. Lets not enshine the dumbest practices of the IT world. I think homenet should focus on L3. (and be clear on what it expects from the other layers with regards to security). cheers, Ole Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
In message ede9b41f-4de6-4e01-a4fc-ac03aff5f...@fugue.com Ted Lemon writes: On Oct 12, 2011, at 4:48 AM, Ole Troan wrote: using the electricity network as an analogy, can we make a distinction between safety and security? the electricity network in the home is somewhat self protecting with breakers and earthing. a home network must protect 'itself', i.e. handle any device plugged into it, in any topology, external and internal attacks and so on. I am highly sympathetic to the desire not to try to solve this problem. However, unfortunately network topology isn't the same as electrical topology, for a couple of reasons. The first reason is that electrical systems are generally set up by professionals. Yes, you plug devices into the electrical wiring of your house, but someone skilled set it up (or if not, I hope you sleep in asbestos pajamas). The devices we are talking about are more analogous to circuit distribution panels than to toasters. The second reason is that electrical systems are essentially topology-free. Any point on the system is essentially equivalent to any other. This is not true of a home network with routing. What we are talking about is essentially the possibility of rogue distribution panels intentionally or accidentally being connected to your distribution system. =20 The electricity analogy is not very useful. Maybe best to drop it. Which is a result of the third reason: home networks are typically wireless, or partially wireless, and so there is no physical security, unlike an electrical network in a house, which is secure by virtue of being entirely enclosed by the house. I think what you are getting at is that we cannot be responsible for securing the network. And that is probably true. But if the system doesn't have a built-in mechanism for distinguishing between friend and stranger, the autoconfiguration mechanism will create topologies that aren't desired, either by accident or because a stranger wants access to the network. If applications are secure, the only threat to a wide open network is theft of service. WPA provides a knob to stop that. The only question is whether WPA or any WiFi security should be enabled by default. Is it better to leave the possibility of theft of service or is it better to have the device unusable by default (until configured)? For provider equipment that is always configured, the latter (unusable until configured). For home equipment where the customer wants to unpack the box, plug it in and use it, the former is better (make it usabled but allow possible theft of service). Every WiFi product I ever bought was open WiFi as shipped. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] security question for zeroconf stuff inside the homenet...
Hi, I've been reading the list with interest and have a question. When various devices in the home figure out which does what, and do that periodically to handle changes, there's clearly the potential that a zombied host tries to try take over stuff with undesirable consequences. My question is whether this group are planning to think about that now, or later, or never? (Or don't even think there's a problem worth attempting to address.) Note - I'm not trying to argue for any particular level of security and certainly not for some unachievable fort knox everywhere, I'm just asking what's the plan? S. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
On Oct 11, 2011, at 9:03 PM, Michael Richardson wrote: However, I am thinking that we can perhaps bootstrap equipment that has never been configured (or has been factory reset) in some fashion such that if the equipment is virginal that it can essentially always try some default keys, and bring up enough networking to let all equipment be discovered and identified. There would be strong nag screens to get the user to up a network password. A pre-shared key that is pre-shared to every device is the same as no key. So you might as well not bother with that complexity. Conceivably CGA could be used to publish public/private key pairs allowing devices to automatically recognize each other and present their relationships in a UI for the end user to approve, but that's not precisely plug and play. I think the simplest thing would be to require that each device be able to talk to a USB drive. Each device collects all the public keys on the USB drive, and stores their own there. Devices then share their public key with other devices identified on the USB drive, so that as each device joins the network, the other devices learn about it. This isn't bulletproof—an infected PC that's configured with these keys could be used to gain access to the keys, for example. But it's a lot better than a well-known key. Of course, this isn't quite as plug and play as you seem to want, and it requires that each device have a USB port, which might not be acceptable. Plus, it would mean that the IETF would have to talk about hardware, which seems like a bit of a non-starter. But I think it's the right way to solve the problem. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
On 10/11/11 18:38 , Ted Lemon wrote: On Oct 11, 2011, at 9:03 PM, Michael Richardson wrote: However, I am thinking that we can perhaps bootstrap equipment that has never been configured (or has been factory reset) in some fashion such that if the equipment is virginal that it can essentially always try some default keys, and bring up enough networking to let all equipment be discovered and identified. There would be strong nag screens to get the user to up a network password. A pre-shared key that is pre-shared to every device is the same as no key. Not really, it could serve an important hygenic function, notionaly, it could be filtered by default on all non-home-network gear. that is serves the purpose of identifying a well-known-service. there are of course other perhaps better ways to implment that. So you might as well not bother with that complexity. Conceivably CGA could be used to publish public/private key pairs allowing devices to automatically recognize each other and present their relationships in a UI for the end user to approve, but that's not precisely plug and play. I think the simplest thing would be to require that each device be able to talk to a USB drive. Each device collects all the public keys on the USB drive, and stores their own there. Devices then share their public key with other devices identified on the USB drive, so that as each device joins the network, the other devices learn about it. This isn't bulletproof—an infected PC that's configured with these keys could be used to gain access to the keys, for example. But it's a lot better than a well-known key. Of course, this isn't quite as plug and play as you seem to want, and it requires that each device have a USB port, which might not be acceptable. Plus, it would mean that the IETF would have to talk about hardware, which seems like a bit of a non-starter. But I think it's the right way to solve the problem. ___ 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
