Re: [homenet] Creating a security association via physical link + button
On Fri, Nov 25, 2011 at 17:43, Mark Townsley towns...@cisco.com wrote: Before we decide that we must have an IGP, that it must be cryptographically secured, and that we have to tackle key distribution for it, I'd like to take a step or two back from the routing protocol part of the equation. I'm not saying we need to secure the IGP. I'm saying that we need homenet devices to know if they're part of the same homenet or not. This is important for border detection, among other things. One easy way to do this, if you have an IGP anyway, is to say that all the devices that are part of the same IGP domain, (and thus share the same key), are on the same homenet. It might - just - be possible for users to understand that to join the network you need the password for the network. Then all you need to do is find a way to share a key. This simple solution falls over if a device needs to be part of two homenets at the same time, or if you want to merge two homenets. Is that clearer now? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Creating a security association via physical link + button
In my experience, there is no single mechanism for establishing what is alternatively called 'pairing,' 'introduction,' 'enrollment,' on in the case of the WiFi Protected Setup a 'mental model.' The techniques have been called ceremonies by Carl Ellison and Jesse Walker, and they serve as a replacement for a system administrator in an unmanaged network by automating the process of adding an authorization, such as to a public key, username/password or other credential. The security rests on showing locality and control of the device, which doesn't work well if the gateway or device is in some publicly-accessible location, which is usually not the case in a home. The efficacy of any particular technique depends on the capabilities of the devices that are being paired. Some research at UC-Irvine, for example, suggests that a short authentication string is the most usable method for most people in cases where there is a keypad or display. In other cases, the USB key and p ush-button configuration techniques may be suitable. I am not aware of any studies that push button is a particularly intuitive HCI for most people. PBC uses weak identification and has a lot of vulnerabilities that require various mechanisms such as walk time in the WPS specification. For homenet, I would expect that we would use or adapt the 'mental models' of the WiFi Alliance for our purposes. Or at least we should consider this course. In the case of the NFC mental model, I believe that particular method has been withdrawn by the WFA due to a dearth of shipped implementations that use it. I am also not aware of interoperable implementations of the USB key WPS technique. As I understand it, new techniques can be introduced or deprecated techniques can be re-introduced at the behest of interested parties. Mark ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Creating a security association via physical link + button
I've been following this thread with interest. Some points (from someone who has a particular 802.15.4-based mesh networking viewpoint): * There probably isn't any need to specify cryptographic security for an IGP on the basis that the packets are link-local and can therefore be protected at L2. * Network access control can set up secure channels to deliver keying information. Therefore in theory this can be used to deliver keying information for any protocols, although in practice it is often just L2 keying information. The focus then turns to which credentials are used for network access control. Whilst I support the use of public key crypto., it is not essential for homenet and there are solutions (not perfect, IMHO, but adequate) which exist now for easy joining (e.g. WPS) based on a pre-shared key/passphrase. Having said that, the burden and complexity of using public key crypto. for network access and mutual authentication is perhaps not as great as one may think. * The original question was about merging networks in the home. Again, I don't think it is that complex if dealt with from a network access point of view. Whether one becomes secondary and assumes the keying information from the primary network (probably preferable if the topology is a mesh) or the two simply join at a common router and retain their own keying information, either is possible and not difficult. Robert On 26/11/2011 6:18 AM, Randy Turner wrote: You maybe right about the equivalent key-management scope, however, I believe any work in the key distribution area applied to the integrity of routing updates would pay off more than expending this effort on the confidentiality of routing update problem. One of the devices we are considering as a router in the Homenet is a Windows machine where the end user has simply turned on internet connection sharing (ICS). Assuming this machine is their home PC, we're talking about the target of practically every attack profile on the internet, so I think it's worth the effort to establish a trust model. Even an android-based phone could inject false (untrusted) routes into the Homenet, but then again I'm getting ahead of myself in pre-supposing attack vectors on the Homenet. I'm keeping an open mind on all of this until we have a document or other work that performs the due diligence on threats to the Homenet. Randy On Nov 25, 2011, at 5:17 PM, Mark Townsley wrote: On Nov 25, 2011, at 6:28 PM, Ted Lemon wrote: On Nov 25, 2011, at 7:30 AM, Randy Turner wrote: I think I agree that confidentiality of routing traffic is probably not an issue for Homenet - however, I do think we should consider integrity of routing traffic - ie, router A should trust that route updates from router B are correct. Exactly. I see no difference really between the difficulty between an integrity-only solution and a confidentiality solution. Both require keys. It's the keys that are the real problem, not the work done on the packets. And, yes, key exchange being hard is based on a certain amount of intuition for my part as well. - Mark That being said, this is just an intuitive feeling regarding security - maybe we need someone to work on a threat analysis and what the implications could be to the types of applications we anticipate Yes, I think this would be worthwhile. I'm certainly arguing based on intuition at the moment. ___ homenet mailing list homenet@ietf.org mailto:homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet smime.p7s Description: S/MIME Cryptographic Signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Creating a security association via physical link + button
I agree - once we have a threat document, this should one of the security models on which we map the threats. Thanks, Acee On Nov 26, 2011, at 4:52 AM, Robert Cragie wrote: I've been following this thread with interest. Some points (from someone who has a particular 802.15.4-based mesh networking viewpoint): There probably isn't any need to specify cryptographic security for an IGP on the basis that the packets are link-local and can therefore be protected at L2. Network access control can set up secure channels to deliver keying information. Therefore in theory this can be used to deliver keying information for any protocols, although in practice it is often just L2 keying information. The focus then turns to which credentials are used for network access control. Whilst I support the use of public key crypto., it is not essential for homenet and there are solutions (not perfect, IMHO, but adequate) which exist now for easy joining (e.g. WPS) based on a pre-shared key/passphrase. Having said that, the burden and complexity of using public key crypto. for network access and mutual authentication is perhaps not as great as one may think. The original question was about merging networks in the home. Again, I don't think it is that complex if dealt with from a network access point of view. Whether one becomes secondary and assumes the keying information from the primary network (probably preferable if the topology is a mesh) or the two simply join at a common router and retain their own keying information, either is possible and not difficult. Robert On 26/11/2011 6:18 AM, Randy Turner wrote: You maybe right about the equivalent key-management scope, however, I believe any work in the key distribution area applied to the integrity of routing updates would pay off more than expending this effort on the confidentiality of routing update problem. One of the devices we are considering as a router in the Homenet is a Windows machine where the end user has simply turned on internet connection sharing (ICS). Assuming this machine is their home PC, we're talking about the target of practically every attack profile on the internet, so I think it's worth the effort to establish a trust model. Even an android-based phone could inject false (untrusted) routes into the Homenet, but then again I'm getting ahead of myself in pre-supposing attack vectors on the Homenet. I'm keeping an open mind on all of this until we have a document or other work that performs the due diligence on threats to the Homenet. Randy On Nov 25, 2011, at 5:17 PM, Mark Townsley wrote: On Nov 25, 2011, at 6:28 PM, Ted Lemon wrote: On Nov 25, 2011, at 7:30 AM, Randy Turner wrote: I think I agree that confidentiality of routing traffic is probably not an issue for Homenet - however, I do think we should consider integrity of routing traffic - ie, router A should trust that route updates from router B are correct. Exactly. I see no difference really between the difficulty between an integrity-only solution and a confidentiality solution. Both require keys. It's the keys that are the real problem, not the work done on the packets. And, yes, key exchange being hard is based on a certain amount of intuition for my part as well. - Mark That being said, this is just an intuitive feeling regarding security - maybe we need someone to work on a threat analysis and what the implications could be to the types of applications we anticipate Yes, I think this would be worthwhile. I'm certainly arguing based on intuition at the moment. ___ 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 smime.p7s Description: S/MIME cryptographic signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Creating a security association via physical link + button
On Nov 26, 2011, at 4:52 AM, Robert Cragie wrote: Network access control can set up secure channels to deliver keying information. It sounds like you're talking about some kind of central management software/protocol here. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Creating a security association via physical link + button
Before we decide that we must have an IGP, that it must be cryptographically secured, and that we have to tackle key distribution for it, I'd like to take a step or two back from the routing protocol part of the equation. First things first, we have to detect that there is a device present, whether it is a router or not, and if so what kind of router to router border we have on that link so that we can apply a policy. If that policy allows sending and receiving of addressing and routing information, from the perspective of the routing protocol it has every thing it needs to start sending IGP packets in the clear on that link. In terms of usability, the homenet cannot afford crypto security or key exchange at every layer. I think we must inherently trust security from layer 2 or physical, just like we do today between routers and hosts (or nat-routers and nat-routers for IPv4) in the home. In practical terms, I think this means that if two routers are connected with a physical link, that link should be trusted enough to send packets, in the clear, which can at least identify what kind of router to router link this is (e.g., local, ISP, etc.). The same applies if two routers are connected over a secured wireless L2 link. Similarly, a wired broadband or 3G/LTE wireless connection to an ISP router in the neighborhood has its own authentication and policy enforcement happening at L2. In terms of UI, if one of those two routers is actually a PC or phone, we shouldn't worry about the pairing issues much as there is enough user interaction to sort that out (I do think that the state of the art could be improved here, but that's for the UI wizards make better, not protocol hacks like us). The most problematic real-world case today that comes to mind would be in how to establish homenet routers that are connected via a wireless link should be considered part of the same network. A link+button might be the best way to make this happen for some routers, but others might prefer a UI from a PC (e.g., the airport utility) with passwords. I think the furthest we can go here is to say that such a link must exist, and what the minimum level of packet exchange should be allowed before discovering what type of router-to-router link is present. - Mark On Nov 25, 2011, at 1:46 AM, Lorenzo Colitti wrote: On Fri, Nov 25, 2011 at 01:27, Ted Lemon mel...@fugue.com wrote: If one is a member of a homenet and an ISP connection already, and one has a blank config, then you might assume that the one with the blank config should join the existing homenet. What if they both have a config on them? What if you're actually merging two separate networks? I think that's the idea. The user is saying merge the two networks in this case. Ok, so it would seem to me that to support that case then we need to either a) support multiple simultaneous keys in the IGP or b) provide a mechanism to tell a number of homenet routers that the key to the IGP is changing. Both are non-trivial. Any other ideas? ___ 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] Creating a security association via physical link + button
Similarly, a wired broadband or 3G/LTE wireless connection to an ISP router in the neighborhood has its own authentication and policy enforcement happening at L2. I'm curious if we want to assume a particular type of broadband connection is in use, or do we want the Homenet solution to be broadband-agnostic, and supply a robust solution without any knowledge of ISP/NSP connectivity method? If we make no assumptions, then our work is harder - if we assume certain types of links in place, then we may or may not fail in certain Homenet connectivity scenarios where our assumptions are incorrect, but the scope of our work will be less. Randy On Nov 25, 2011, at 12:43 AM, Mark Townsley wrote: Before we decide that we must have an IGP, that it must be cryptographically secured, and that we have to tackle key distribution for it, I'd like to take a step or two back from the routing protocol part of the equation. First things first, we have to detect that there is a device present, whether it is a router or not, and if so what kind of router to router border we have on that link so that we can apply a policy. If that policy allows sending and receiving of addressing and routing information, from the perspective of the routing protocol it has every thing it needs to start sending IGP packets in the clear on that link. In terms of usability, the homenet cannot afford crypto security or key exchange at every layer. I think we must inherently trust security from layer 2 or physical, just like we do today between routers and hosts (or nat-routers and nat-routers for IPv4) in the home. In practical terms, I think this means that if two routers are connected with a physical link, that link should be trusted enough to send packets, in the clear, which can at least identify what kind of router to router link this is (e.g., local, ISP, etc.). The same applies if two routers are connected over a secured wireless L2 link. Similarly, a wired broadband or 3G/LTE wireless connection to an ISP router in the neighborhood has its own authentication and policy enforcement happening at L2. In terms of UI, if one of those two routers is actually a PC or phone, we shouldn't worry about the pairing issues much as there is enough user interaction to sort that out (I do think that the state of the art could be improved here, but that's for the UI wizards make better, not protocol hacks like us). The most problematic real-world case today that comes to mind would be in how to establish homenet routers that are connected via a wireless link should be considered part of the same network. A link+button might be the best way to make this happen for some routers, but others might prefer a UI from a PC (e.g., the airport utility) with passwords. I think the furthest we can go here is to say that such a link must exist, and what the minimum level of packet exchange should be allowed before discovering what type of router-to-router link is present. - Mark On Nov 25, 2011, at 1:46 AM, Lorenzo Colitti wrote: On Fri, Nov 25, 2011 at 01:27, Ted Lemon mel...@fugue.com wrote: If one is a member of a homenet and an ISP connection already, and one has a blank config, then you might assume that the one with the blank config should join the existing homenet. What if they both have a config on them? What if you're actually merging two separate networks? I think that's the idea. The user is saying merge the two networks in this case. Ok, so it would seem to me that to support that case then we need to either a) support multiple simultaneous keys in the IGP or b) provide a mechanism to tell a number of homenet routers that the key to the IGP is changing. Both are non-trivial. Any other ideas? ___ 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] Creating a security association via physical link + button
On Nov 25, 2011, at 6:28 PM, Ted Lemon wrote: On Nov 25, 2011, at 7:30 AM, Randy Turner wrote: I think I agree that confidentiality of routing traffic is probably not an issue for Homenet - however, I do think we should consider integrity of routing traffic - ie, router A should trust that route updates from router B are correct. Exactly. I see no difference really between the difficulty between an integrity-only solution and a confidentiality solution. Both require keys. It's the keys that are the real problem, not the work done on the packets. And, yes, key exchange being hard is based on a certain amount of intuition for my part as well. - Mark That being said, this is just an intuitive feeling regarding security - maybe we need someone to work on a threat analysis and what the implications could be to the types of applications we anticipate Yes, I think this would be worthwhile. I'm certainly arguing based on intuition at the moment. ___ 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] Creating a security association via physical link + button
Mark, Actually, I suggested that wired wouldn't need any key handshake. Wireless would, and such handshakes require UI. The UI is the problem if there are two devices that are not used to having any serious UI. I'm not sure I know how to solve that, but I'm not sure it's our problem to solve either. Take Wi-Fi for example, WPS PBC requires no UI. WPS PIN. Hans ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Creating a security association via physical link + button
On Tue, Nov 22, 2011 at 23:54, Ted Lemon mel...@fugue.com wrote: Yeah, I don't think either device decides that it is the homenet; rather, they are regularly dynamically discovering topology, and deciding what to do based on whether they are connected to an edge. Possibly both devices are connected to an edge, and cooperate to do multihoming. Let me rephrase my original question. You connect two routers and press the button on both. What happens, and who gets the config from whom? If one is a member of a homenet and an ISP connection already, and one has a blank config, then you might assume that the one with the blank config should join the existing homenet. What if they both have a config on them? What if you're actually merging two separate networks? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Creating a security association via physical link + button
On Fri, Nov 25, 2011 at 01:27, Ted Lemon mel...@fugue.com wrote: If one is a member of a homenet and an ISP connection already, and one has a blank config, then you might assume that the one with the blank config should join the existing homenet. What if they both have a config on them? What if you're actually merging two separate networks? I think that's the idea. The user is saying merge the two networks in this case. Ok, so it would seem to me that to support that case then we need to either a) support multiple simultaneous keys in the IGP or b) provide a mechanism to tell a number of homenet routers that the key to the IGP is changing. Both are non-trivial. Any other ideas? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Creating a security association via physical link + button
how cheap? it depends -- whether you're talking about retail, or the bare bones prices being demanded by NSPs from box vendors and whether or not these NSPs have a broad and popular suite of homenet services to allow subsidizing the boxes The overall point here is that these boxes probably have to hit very inexpensive price points...easily sub $50 to the NSPs R. Original message Subject: Re: [homenet] Creating a security association via physical link + button From: Ted Lemon mel...@fugue.com To: Howard, Lee lee.how...@twcable.com CC: homenet@ietf.org homenet@ietf.org,Lorenzo Colitti lore...@google.com On Nov 22, 2011, at 5:19 PM, Howard, Lee wrote: I don’t want to do mechanical engineering here. And buttons are expensive. Great, let's just do a USB port then! :) Seriously, if you make a device cheap enough, it simply won't be able to do homenet. The question is, how cheap is that? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Creating a security association via physical link + button
On Nov 22, 2011, at 7:42 AM, Russ White wrote: This is, generally speaking, how current home routers work... And, I think, it might be the only way to make a homenet work. The primary key beyond this is a device being able to figure out I'm an edge to the outside world. Yeah, I don't think either device decides that it is the homenet; rather, they are regularly dynamically discovering topology, and deciding what to do based on whether they are connected to an edge. Possibly both devices are connected to an edge, and cooperate to do multihoming. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Creating a security association via physical link + button
Home routers with a natural WAN interface such as DSL or Docsis are built from reference designs that hardwire the internet interface, including any firewall-like functionality Randy Original message Subject: Re: [homenet] Creating a security association via physical link + button From: Ted Lemon mel...@fugue.com To: Russ White ru...@riw.us CC: homenet@ietf.org,Lorenzo Colitti lore...@google.com On Nov 22, 2011, at 7:42 AM, Russ White wrote: This is, generally speaking, how current home routers work... And, I think, it might be the only way to make a homenet work. The primary key beyond this is a device being able to figure out I'm an edge to the outside world. Yeah, I don't think either device decides that it is the homenet; rather, they are regularly dynamically discovering topology, and deciding what to do based on whether they are connected to an edge. Possibly both devices are connected to an edge, and cooperate to do multihoming. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Creating a security association via physical link + button
A physical button, or a virtual button? I don't want to do mechanical engineering here. And buttons are expensive. Lee From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On Behalf Of Lorenzo Colitti Sent: Tuesday, November 22, 2011 3:02 AM To: homenet@ietf.org Subject: [homenet] Creating a security association via physical link + button It would be cool if I could plug in a new router into my homenet, press a special button on it and on the router I plug it into, and have the new router download the homenet config (at least the routing protocol key, but maybe other things like the wifi SSID) from the existing router. The button would cause the existing router to make the information available in the clear for, say, 30 seconds, and would cause the new router to attempt to fetch it from a directly connected neighbour. The combination of physically plugging something in and pressing the button might provide enough security to defend against unintended pairings (e.g., because you plugged something in to the wrong port; maybe to your neighbour's homenet). I don't know how you would decide who is the homenet and who is the new router though. Comments? This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet