Re: [homenet] HNCP security?
On Wed, 24 Sep 2014, Markus Stenberg wrote: Big problem with IPsec + ‘any protocol’ is that it does not work _that_ well with multicast. Certainly, you can use manually keyed (static) IPsec SAs (although in case of Linux, out of the box, it does not work either but is easy to patch), but they have somewhat worse security properties, main things being lack of replay protection and fixed key used for crypto. How does multicast work at all with replay-protection? I am not a crypto guy, but is there any way of doing multicast and not have this problem? Is there something else that'll work as transport layer security for multicast, or should we send a request for the IETF leadership to investigate if this is something that needs to be developed? I just can't help seeing this problem popping up all over the place and everybody solving it by writing their own code and doing their own implementation. IPSEC isn't widely used because it doesn't have ports so it can't be NATed (so its now run over UDP to workaround that problem) and also because key management is hard because keys are managed by the operating system and not by the application? So, do we need a mix between IPSEC and TLS that can be done on a per-application level, but it's still a generic framework so that someone can develop generic code that projects like HNCP can use, for instance by linking to libraries? -- Mikael Abrahamssonemail: swm...@swm.pp.se___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On 24.9.2014, at 12.07, Mikael Abrahamsson swm...@swm.pp.se wrote: On Wed, 24 Sep 2014, Markus Stenberg wrote: Big problem with IPsec + ‘any protocol’ is that it does not work _that_ well with multicast. Certainly, you can use manually keyed (static) IPsec SAs (although in case of Linux, out of the box, it does not work either but is easy to patch), but they have somewhat worse security properties, main things being lack of replay protection and fixed key used for crypto. How does multicast work at all with replay-protection? I am not a crypto guy, but is there any way of doing multicast and not have this problem? Well, effectively per-source replay window _and_ rekeying to make e.g. system restarts not be vulnerable to this. I don’t remember how GSA in msec was specified anymore, but it is not intractable problem (at least in theory). It has been many years since I read msec work though. Is there something else that’ll work as transport layer security for multicast, or should we send a request for the IETF leadership to investigate if this is something that needs to be developed? There is not that I know of. I believe msec work is somewhat outdated (based on IKEv1, and not widely deployed), but security isn’t popular, and multicast isn’t popular, so combining them is not usually win in IETF. (And especially in seeing them implemented - still not sure how many msec implementations there has been.) I just can't help seeing this problem popping up all over the place and everybody solving it by writing their own code and doing their own implementation. IPSEC isn't widely used because it doesn't have ports so it can't be NATed (so its now run over UDP to workaround that problem) and also because key management is hard because keys are managed by the operating system and not by the application? So, do we need a mix between IPSEC and TLS that can be done on a per-application level, but it’s still a generic framework so that someone can develop generic code that projects like HNCP can use, for instance by linking to libraries? TLS + (pure) multicast is more or less impossible. You could probably define pure-multicast key negotiation scheme too using multi-party D-H (for example), but I am not sure if there is any standard protocols for that. Still, it would not look like TLS so calling it e.g. MTLS would be somewhat misleading. You could use some packet encoding features, but that would be that. I guess you could do some sort of msec GDOI-like solution for it too - perform unicast exchanges using something like DTLS encoding of TLS handshakes to agree on multicast encryption key to be used on DTLS-ish ESP-ish UDP multicast traffic with per-source replay windows. Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Sep 23, 2014, at 7:22 PM, Michael Richardson mcr+i...@sandelman.ca wrote: Mark Townsley m...@townsley.net wrote: My own experience attempting to use IPsec as an add-on security solution (a.k.a. pixie dust) for a protocol isn't all that positive. We tried that with L2TP, and in the process failed to kill off PPTP on windows clients. I can't tell you how many times over the years I've had to point people to the Windows Registry setting to disable IPsec with L2TP. OSPFv3 is another one where I get complaints about requiring IPsec. So, I agree with Ted; We should be wary of falling into the trap of using IPsec just because it is there. That's a poor example for several reasons that have nothing to do with HNCP, and so I won't go into them here. (and I do have tons of L2TP code in the field, sadly) Michael, Back in '97 or so, the IETF weighed draft-ietf-pppext-l2tp-sec vs. L2TP+IPsec, and chose the latter (now RFC 3193). Some of this thread reminds me of discussions we had at that time, not just HNCP+IPsec vs. HNCPsec on the wire, but also whether we consider key config and such within HNCP alone or more holistically. Everyone has their own reference historical points to draw from, that was just my own. Sorry it didn't work for you! Cheers, - Mark -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Working Group draft adoptions
Thanks for the review, late is still welcome. As for IPv4, as you alluded to, we are chartered to develop solutions that work dual-stack where we can, as long as we are not making harmful concessions to the v6 design due to v4 consideration. - Mark (Thumbtyped) On Sep 23, 2014, at 11:41 PM, Michael Richardson m...@sandelman.ca wrote: Late, but: I have read draft-pfister-homenet-prefix-assignment. Adopt it. I thought I read it before, but maybe not. It all seems familiar, but what's with all the IPv4 stuff? I guess we are doing an IPv4 thing, because we can, and it's useful to be able to turn off detect that have multiple potential DHCPv4 servers, and turn them off if we can. I think that we should remove: If the delegated prefix is too small given the size of the network, prefixes of arbitrary lengths may be used. and stick to 64-bit for all the why-64 reasons. Let's not talk about any other options.This document also seems to interoperate with (CableLabs) HIP. draft-mglt-homenet-front-end-naming-delegation draft-mglt-homenet-naming-architecture-dhc-options I have read previous versions of these documents, and upon looking again, I see lots of shiny new text, and I like it all. While there are many people who are very scared of having home devices in DNS, and many are worried that they will be forced somehow to do so, I don't think any such comments matter. This is, like almost all protocols the IETF creates, optional to enable. Please adopt these documents. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails [ ___ 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] HNCP security?
Thank you for all of the discussion on this important topic. Without declaring consensus on how far we should go scope-wise in terms of overall homenet security just yet, I'd like to know if, in terms of HNCP itself from a bits-on-the-wire protocol perspective, can we adopt this proposal proposal from Mikael? If yes, please say so. If no, please say why not (and even better if you can propose text that would alleviate your concern). Mikael Abrahamsson wrote: So my proposal is that we make HNCP capable of using several methods, one is unsecure, one is secure by means of a shared secret, and then add other optional methods using PKI that would enable the above mentioned accept each device manually more secure way. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
Mark Townsley m...@townsley.net wrote: Without declaring consensus on how far we should go scope-wise in terms of overall homenet security just yet, I'd like to know if, in terms of HNCP itself from a bits-on-the-wire protocol perspective, can we adopt this proposal proposal from Mikael? If yes, please say so. If no, please say why not (and even better if you can propose text that would alleviate your concern). It is essentially identical to what I am proposing. I would motify slightly: 1) the I in PKI is inappropriate. 2) not-yet-secure nodes should be able to listen to secured traffic. Mikael Abrahamsson wrote: So my proposal is that we make HNCP capable of using several methods, one is unsecure, one is secure by means of a shared secret, and then add other optional methods using PKI that would enable the above mentioned accept each device manually more secure way. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- pgpq4E2ll1EUv.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
Thank you for all of the discussion on this important topic. Without declaring consensus on how far we should go scope-wise in terms of overall homenet security just yet, I'd like to know if, in terms of HNCP itself from a bits-on-the-wire protocol perspective, can we adopt this proposal proposal from Mikael? If yes, please say so. If no, please say why not (and even better if you can propose text that would alleviate your concern). ACK. It's similar to my own proposal regarding bits-on-the-wire anyway. Maybe adding that we should try to use an existing and well-tested mechanism unless there is a very good reason not to. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Sep 24, 2014, at 10:00 AM, Steven Barth cy...@openwrt.org wrote: Maybe adding that we should try to use an existing and well-tested mechanism unless there is a very good reason not to. I don't think there is one, but if you think there is you should tell us! :) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
Michael Thomas m...@mtcc.com wrote: Michael Thomas m...@mtcc.com wrote: 2) ISP-provided router has to be willing to trust retail purchased router, or nothing works. So what about the other way around? To what degrees should my homenet trust ISP-maintained CPE? That's up to you. Seriously. Your ISP-maintained CPE totally p0wns your network. If you don't trust them, even just a little bit, then you can't use their equipment. And there's nothing we can do about that, even if we define a boundary such that they are outside it? You can run another router inside, and if the ISP router supports being a DHCPv6-PD (such as proposed by HIP), you might win. Otherwise, you might as well stick with IPv4+NAT, I think (maybe with v6 in a tunnel). Me, I just buy by own router + modem, and I can't get a modem, many ISPs understand when you want to turn their router into a modem only. I'm no expert here, but it seems to me that the normal first hop ISP router doesn't have these characteristics of p0nwage for in-home traffic? Right now, with IPv4 only, the ISP provided router (which usually includes wifi) completely p0wns the house. I believe that when you get DSL from free.fr, that they actually put up another ESSID which accepts VoIP traffic From their mobile phone subscribers. That's why free.fr is so inexpensive; the DSL subscribers provide the mobile phone infrastructure. (free.fr is open about this. I've long suspected Bell Canada wants to do the same thing, and I observe them essentially squatting on wifi channels all over the place) -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- pgpcwZctKZ02C.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
