Re: [homenet] HNCP Security Trust Draft
I just pushed a new revision of the draft. http://tools.ietf.org/html/draft-barth-homenet-hncp-security-trust-01 Most notable changes: * Some clarifications to the consensus based trust scheme * PSK-management now supports key-derivation for different protocols (IGPs, ...) * Underlying crypto scheme changed to DTLS for now * Some spellchecking, idnits etc. Am Freitag, den 03.10.2014, 20:38 +0200 schrieb Steven Barth: Hi everyone, I took the last few days to gather some thoughts about threats, security and trust management in the context of HNCP and wrote it up under http://tools.ietf.org/html/draft-barth-homenet-hncp-security-trust-00 Quick overview over the topics: * Homenet Border * HNCP Payload Security * Trust Management * IGP-Considerations Please note that this draft is in a very early stage so please help to make additions, provide feedback and point out mistakes. Regards, Steven ___ 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 Trust Draft
1) i was hopeful that this might be a threats kind of draft which is sorely needed. i was disappointed. 2) there is a huge set of possibilities in between PSK and PKI in section 6.1 and 6.2. see #1. Mike On 10/14/2014 12:37 AM, Steven Barth wrote: I just pushed a new revision of the draft. http://tools.ietf.org/html/draft-barth-homenet-hncp-security-trust-01 Most notable changes: * Some clarifications to the consensus based trust scheme * PSK-management now supports key-derivation for different protocols (IGPs, ...) * Underlying crypto scheme changed to DTLS for now * Some spellchecking, idnits etc. Am Freitag, den 03.10.2014, 20:38 +0200 schrieb Steven Barth: Hi everyone, I took the last few days to gather some thoughts about threats, security and trust management in the context of HNCP and wrote it up under http://tools.ietf.org/html/draft-barth-homenet-hncp-security-trust-00 Quick overview over the topics: * Homenet Border * HNCP Payload Security * Trust Management * IGP-Considerations Please note that this draft is in a very early stage so please help to make additions, provide feedback and point out mistakes. Regards, Steven ___ 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] HNCP Security Trust Draft
On Fri, 3 Oct 2014, Steven Barth wrote: Please note that this draft is in a very early stage so please help to make additions, provide feedback and point out mistakes. Being a crypto novice, let me write some text and please tell me if it makes sense in the context of your draft (thanks for writing it, it looks like a good summary). I like SSH. SSH generates its own public/private key, there are fingerprints I can put in SSHFP DNSSEC secured posts, etc. Are the public/private keys considered to be similar to self-signed certificates? Anyhow, let me propose a scenario: I get my first homenet router and power it up. It comes with a QR code on it, and it has a button (or NFC, similar principle). I scan the QR code on my smartphone (with a special homenet-control-app) which gives it enough information to connect to the wifi of the router, then I am asked to press a button on the router to allow my phone to become the administration device. The QR code contains wifi information and key fingerprint ID so my phone can decide that it's speaking to the correct device. Now, after this, my phone app can speak to the router, and when I hook up another device to that router, it detects the new device, fingerprint ID etc, and asks me before it's allowed. After I ACK that it's allowed to talk to my homenet (which previously only consisted of a single router), they exchange session keys (or something) for management, so they can continue to talk. Just like with SSH allowing key based login, the management of homenet devices would rely on the public key for each accepted device being known to all the other devices, and this is how things authenticate. This would be the anchor that everything else relies on when it comes to security. Now, the problem is what to do when I lose my phone and don't have any backup, so perhaps I need a user/password based login to add new administration devices, it seems hard to work around. If someone gets the private key of any of the accepted homenet devices, of course everything falls down, but I don't see any way around it apart from having TPM etc. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP Security Trust Draft
Hi Mikael, thanks for your feedback. Being a crypto novice, let me write some text and please tell me if it makes sense in the context of your draft (thanks for writing it, it looks like a good summary). I do not consider myself to be a crypto expert either which is one of the reasons I'd try to offload the actual crypto to something well-known. Also this probably means that what I drafted might not be 100% accurate but I hope some of the actual expert will review it. I like SSH. SSH generates its own public/private key, there are fingerprints I can put in SSHFP DNSSEC secured posts, etc. Are the public/private keys considered to be similar to self-signed certificates? I'll answer this in the context of the consensus based trust-scheme I added in addition to the PSK and PKI-based trust scheme. Yes, using self-signed certs here is possible since it's simply X.509. Anyhow, let me propose a scenario: I get my first homenet router and power it up. It comes with a QR code on it, and it has a button (or NFC, similar principle). I scan the QR code on my smartphone (with a special homenet-control-app) which gives it enough information to connect to the wifi of the router, then I am asked to press a button on the router to allow my phone to become the administration device. The QR code contains wifi information and key fingerprint ID so my phone can decide that it's speaking to the correct device. Right that would be possible and the QR-code would be an additional trust bootstrap ceremony in that context. I actually had a phone / homenet-app scenario in mind when drafting this. So I was thinking about two possible cases. Case #1: The app is bound to the router itself via some kind of vendor-specific RPC so it can control its configuration directly. That RPC allows the app to read / receive fingerprints and names when a new device attempts to join the homenet and allows the user to give a verdict (trusted / untrusted) which is then announced by the router itself and not the phone. Case #1 is pretty obvious because it isn't really problematic and not bound to the phone itself and you could probably do the using some kind of webinterface on such a router. Case #2: The app itself speaks HNCP, i.e. the base state synchronization part (not the routing, addressing, SD whatever). It is standalone (i.e. doesn't depend on a specific router, just has to peered with any HNCP router once so it is trusted) from then on it can itself announce trust verdicts about other routers. Now, after this, my phone app can speak to the router, and when I hook up another device to that router, it detects the new device, fingerprint ID etc, and asks me before it's allowed. After I ACK that it's allowed to talk to my homenet (which previously only consisted of a single router), they exchange session keys (or something) for management, so they can continue to talk. In Case #1 above it could tell the router to announce a trust verdict (trusted / untrusted) or in Case #2 it would do so by itself. The session key exchange would then be done by the underlying protocol i.e. DTLS, IPsec/IKE, ... The only real addition here should be that this underlying protocol (or its implementation) needs to allow a custom verification hook (i.e. notifies the HNCP daemon that there is a an unknown certificate and allows it to be accepted or not). For DTLS e.g. this shouldn't be problematic since most libraries seem to support such a callback. Just like with SSH allowing key based login, the management of homenet devices would rely on the public key for each accepted device being known to all the other devices, and this is how things authenticate. This would be the anchor that everything else relies on when it comes to security. Yes, each device would announce the fingerprints of the certificates or public keys (details TBD) that it trusts in its HNCP-state. Now, the problem is what to do when I lose my phone and don't have any backup, so perhaps I need a user/password based login to add new administration devices, it seems hard to work around. Each device may announce verdicts about public keys / certificates and verdicts of device which are absent are cached by other HNCP routers so your case and Case #2 above would work without the app/phone always being there. If someone gets the private key of any of the accepted homenet devices, of course everything falls down, but I don't see any way around it apart from having TPM etc. Yeah that's also the downside here. It's even more apparent if anyone can say someone else is trusted or not. But I guess ultimately its the same issue and once you are actually a trusted homenet router you can do more nasty things like messing with routing etc. than actually attacking the trust system itself, especially since most of the algorithms / applications run over HNCP are distributed / consensus based anyway. Cheers, Steven
Re: [homenet] HNCP security?
On 25.9.2014, at 14.19, Tero Kivinen kivi...@iki.fi wrote: Markus Stenberg writes: 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.) There is also ikev2 version of group key management (draft-yeung-g-ikev2), but the draft seems to have expired some time ago. I still think it was supposed to be published. Ah, interesting, did not know about that. Thanks ;) If homenet needs multicast support then it might be good idea to push that document forward. How does this solution work with e.g. link-local-only littleconf-TOFU setup? To be more precise, I am not sure which node would be GCKS, and how other nodes would find that node. Based on cursory read of the draft, it seems to assume that non-GCKS nodes know GCKS address in advance. I do not think replacing the IKEv2 with TLS would help at all. If you go for application level protection then using DTLS or similar is better than getting ESP involved at all. DTLS has rather sad multicast story too (=manually keyed IPsec without IPsec and draft-only at the moment). Of course, whether or not we really have to secure multicast at all in case of HNCP is debatable. However, as a general solution, it is somewhat lacking, as leveraging same thing for e.g. bit more multicast-heavy routing protocols would not work in case of DTLS (then again, I am not sure if GDOI / G-IKEv2 are much better due to them being mostly draft-only vaporware at this point). Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
Hiya, I've not really been following this discussion sufficient to comment in general, but just on this part... On 29/09/14 08:39, Markus Stenberg wrote: DTLS has rather sad multicast story too The DICE WG [1] have also been discussing potential issues with DTLS and multicast. That discussion has turned out harder than envisaged in that the WG originally figured a simple extension to the DTLS reccord layer might suffice to get useful security when DTLS packets are sent via IP multicast. Turns out to be less easy than that. Anyway, if this WG do end up needing some multicast security and are looking at DTLS it would be very good to co-ordinate with the DICE WG. Sooner would be much better than later for that as the DICE WG are right now in the process of (re-)considering whether they can in fact meet their chartered goals on this topic. Thanks, S. [1] https://tools.ietf.org/wg/dice/ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
Markus Stenberg writes: There is also ikev2 version of group key management (draft-yeung-g-ikev2), but the draft seems to have expired some time ago. I still think it was supposed to be published. Ah, interesting, did not know about that. Thanks ;) If homenet needs multicast support then it might be good idea to push that document forward. How does this solution work with e.g. link-local-only littleconf-TOFU setup? I have no idea what littleconf-TOFU setup looks like, so cannot comment.. To be more precise, I am not sure which node would be GCKS, and how other nodes would find that node. Based on cursory read of the draft, it seems to assume that non-GCKS nodes know GCKS address in advance. As the G-IKEv2 uses IKE_SA_INIT from the IKEv2 for the first exchange, the RFC5685 IKEv2 redirect with anycast address (see section 4 of RFC5685) would work with it just fine. I.e. the new device wanting to know the GCKS to talk to would send anycast IKEv2 packet to the network: InitiatorResponder (any VPN GW) -- (IP_I:500 - ANYCAST:500) HDR(A,0), SAi1, KEi, Ni) -- N(REDIRECT_SUPPORTED) (ANYCAST:500 - IP_I:500) -- HDR(A,0), N(REDIRECT, New_GW_ID, Ni_data) (with G-IKEv2 the port number would be the normal G-IKEv2 port, i.e. 848, not 500). I.e. now the router listening this link can reply to the anycast request, with the proper gateway address (which might be his own, if he is the one acting as GCKS). The anycast support for redirect was meant to be used for bootstrapping cases, i.e. where the client does not know yet who to talk to. I do not think replacing the IKEv2 with TLS would help at all. If you go for application level protection then using DTLS or similar is better than getting ESP involved at all. DTLS has rather sad multicast story too (=manually keyed IPsec without IPsec and draft-only at the moment). Of course, whether or not we really have to secure multicast at all in case of HNCP is debatable. However, as a general solution, it is somewhat lacking, as leveraging same thing for e.g. bit more multicast-heavy routing protocols would not work in case of DTLS (then again, I am not sure if GDOI / G-IKEv2 are much better due to them being mostly draft-only vaporware at this point). At least the G-IKEv2 stuff is there, and the actual ESP use of multicast has been defined for manual keys for quite long time (and is in the RFCs already, not only drafts). I have no idea if there is any implementations about the G-IKEv2, but I doubt that there is anything to protect multicast ready now... -- kivi...@iki.fi ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Sep 29, 2014, at 3:50 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: Sooner would be much better than later for that as the DICE WG are right now in the process of (re-)considering whether they can in fact meet their chartered goals on this topic. Unfortunately I think at this point we are distracted by a discussion about whether to use nails or screws when we haven't settled on what kind of house we're building. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On 29/09/14 13:58, Ted Lemon wrote: On Sep 29, 2014, at 3:50 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: Sooner would be much better than later for that as the DICE WG are right now in the process of (re-)considering whether they can in fact meet their chartered goals on this topic. Unfortunately I think at this point we are distracted by a discussion about whether to use nails or screws when we haven't settled on what kind of house we're building. Understood. And I don't want to side-track you here. However, if your house is such that it only requires confidentiality and data integrity of messages between group members, but does not require origin authentication that that'd be useful to know. What I mean by origin authentication here is the ability for the receiver of a multicast message to cryptographically verify exactly which member of the group has sent a message. If, OTOH, you can say that you would in fact also require origin authentication, then that is also of interest. (It'd mean that your use case could not be met by the initially chartered work for DICE, and that factoid could be helpful in figuring out how to handle the DICE work.) Cheers, S. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Sep 29, 2014, at 9:16 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: If, OTOH, you can say that you would in fact also require origin authentication, then that is also of interest. (It'd mean that your use case could not be met by the initially chartered work for DICE, and that factoid could be helpful in figuring out how to handle the DICE work.) I think we definitely need origin authentication, but I am skeptical that we need multicast TLS. I guess if we had it it might work, though. But I'm not convinced it's the right model. So I'd hate to have you guys go off and invent something cool that winds up not matching the eventual design. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On 09/29/2014 06:24 AM, Ted Lemon wrote: On Sep 29, 2014, at 9:16 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: If, OTOH, you can say that you would in fact also require origin authentication, then that is also of interest. (It'd mean that your use case could not be met by the initially chartered work for DICE, and that factoid could be helpful in figuring out how to handle the DICE work.) I think we definitely need origin authentication, but I am skeptical that we need multicast TLS. I guess if we had it it might work, though. But I'm not convinced it's the right model. So I'd hate to have you guys go off and invent something cool that winds up not matching the eventual design. Why might we need *in-session* origin authentication? I'm not questioning it, just trying to understand the threats/requirements. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
Ted Lemon mel...@fugue.com wrote: If, OTOH, you can say that you would in fact also require origin authentication, then that is also of interest. (It'd mean that your use case could not be met by the initially chartered work for DICE, and that factoid could be helpful in figuring out how to handle the DICE work.) I think we definitely need origin authentication, but I am skeptical that we need multicast TLS. I guess if we had it it might work, though. But I'm not convinced it's the right model. So I'd hate to have you guys go off and invent something cool that winds up not matching the eventual design. I think that it useful if we have a simple way to authenticate the multicast'ed communication, but I think it is acceptable to form point to point (unicast) security associations to get the origin authentication. The communication might go like: MULTICAST DrNick: HEY EVERYBODY, I got a new PREFIX to share! UNICAST Homer to DrNick: ... PREFIXES.. can I have some? UNICAST DrNick to Homer: sure, not a problem! [If that sounds like DHCPv6] -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- pgpUR0d2GQ6wI.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
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] 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
Re: [homenet] HNCP security?
Markus Stenberg markus.stenb...@iki.fi wrote: markus 1) Can we assume secure L2 and/or appropriate device markus configuration by the manufacturer/ISP(/user)? (This is what I can markus assume in my own home.) I think that we can assume that wired links are secure. The only time we care if wireless is secured is when we want to form an adjacency over the wireless link. I think it is acceptable to refuse to form an adjancency over an insecured wireless link. This can also be automated (for first-hop wireless). However, in the ‘what-if’ land, wired - wireless bridges, and wireless - wireless extenders that do things insecurely cannot be detected. Yes, I agree. Let me restate that I think we can securely to do TOFU across the wired link. If that link turns into something less secure, then that's okay. I think it is acceptable to do some kind of TOFU (using IPsec with IKEv2 even) point to point across wired links, and having done that, if there is an adjancy later possible between those two devices over what would otherwise be an insecure link, that the previously exchanged keys work. That means one can plug two routers together with a cable, and then separate them, knowning that the two routers will remain entangled (I’m making allusions to http://en.m.wikipedia.org/wiki/Quantum_entanglement) I assume you mean: - On wired links: opportunistic IKEv2 attempt, fallback to non-IPsec (if no IPsec available? if no key?), and update the SPD dynamically based on successful IKEv2 attempts. - On the wireless (all? only insecure?): force IPsec using the known good SPD entries. That is interesting scheme. Implementation-wise, it sounds somewhat painful though. yes, I agree that it's probably difficult with the available implementation of openwrt IKEv2 daemons... I don't think it's architecturally that hard. I further suggest that if two routers have wireless that they might well have a WPA2/PSK available to them, and that they can and SHOULD use something derived from that key to authenticate each other. Could be over IKEv2, yes. I _think_ we have to assume some passwords somewhere. - WPA2 PSK on almost all home routers by default (most home network access these days is wireless) yes, agree. And if they have multiple routers, they likely have the same WPA2-PSK. - admin password (for those user actually has access to, and are not part of some super-fancy PKI scheme for authenticating administrator) I'm less thrilled about using the admin password. They have less likely hood of being changed, and ideally, they are encrypted/hashed in a way that the raw password can't be seen. markus 2) If not, should the solution be some sort of pre-shared key markus scheme? (If not, please explain your alternative solution.) If we assume the abovekey, we could use it to derive a pre-shared key for a multicast IPsec SA using AH. Can we assume, declare, that if you don't know the key, that you skip the AH header, and process the HNCP that is inside as if it wasn't secured at all? We wanted to do that for SEND, but there were IPsec implementations that could do that, because we overspecified AH back in 2401. Given that home routers are purpose built boxes, and not generic random hosts, perhaps we can specify this behaviour. Hmm. I wonder if that assumption would work bidirectionally, though. That is, the not-key-knowing router sending plaintext traffic, and the others using the information? If so, what is the value of having the (optional) authentication at all? If assumption is not bidirectional, then the distributed algorithms would not work very well over such protocol - unless the unauthenticated messages were just used for bootstrapping the trust somehow, but it is not clear to me how that would happen either. Of course, they could be used to show user some error (if the router actually had UI of some kind) but not much else that I can see. That's what I would suggest: unauthenticated messages are to bootstrap trust. Possibly that involves an item on a web page saying, Router XYZ wants to join Stenberg House, permit Y/N, perhaps can flash attention LED on front. That would only be used if the network had been set to paranoid secure, and/or if the wired-TOFU didn't work. markus 2.1) And if so, should it be manually keyed IPsec (multicast markus prevents e.g. IKE)? (This is what is in the draft currently.) Yes, if we can make this AH assumption of skipping, so that we can get TOFU to work. If we assume some psk on all routers, we can probably bootstrap ’something’ without TOFU too? I agree; but I think that TOFU would be useful here, particularly if the router isn't wireless capable. Maybe it is a bridge to
Re: [homenet] HNCP security?
Steven Barth cy...@openwrt.org wrote: And it's extremely unlikely that DTLS will be a one-sentence solution even if it gets adopted because DTLS, IPsec, etc say nothing about enrollment and authorization. Those are by far the hard problems with homenent security. I wouldn't really want to lock HNCP to any trust scheme at this point where we are not even sure what we want. I'd rather choose the underlying mechanism, either DTLS or IPsec/IKE and leave the rest out-of-scope. Maybe mention PSK-usage as baseline option and say various other certificate-based approached are possible but out-of-scope of the HNCP draft itself. With respect, if you leave the trust scheme out of scope, what you are really doing is leaving all of the security out of scope, because it won't be deployable. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- pgpf_Imlo3UTo.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Sep 23, 2014, at 1:23 PM, Michael Richardson mcr+i...@sandelman.ca wrote: With respect, if you leave the trust scheme out of scope, what you are really doing is leaving all of the security out of scope, because it won't be deployable. +1 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
Randy Turner rtur...@amalfisystems.com wrote: Are we assuming that the home router is purchased retail, and not fulfilled or provided by an ISP? The method to establish trust relationships would hinge on the answer 1) if there only one home router from the ISP, then there is no problem. 2) ISP-provided router has to be willing to trust retail purchased router, or nothing works. 3) ISP-A-provided router has to be willing to trust ISP-fullfilled router from ISP-B-provided router. If you have secrets (including WPA-PSK keys) that are on your ISP-fullfilled router, that you want to keep secret from your ISP, then you lost. If you don't trust your ISP, then you can't use your ISP provided router. So the answer does *not* hinge on the answer. It has to work, and I think we can make it work. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- pgpxs_cjQQrXo.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On 9/23/14, 10:59 AM, Michael Richardson 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? Or more succinctly, what are the things the ISP and Retail CPE need to collaborate on and what are the things they need to take an adversarial stance on? Neither me, nor my ISP are similarly motivated, after all. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
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. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- pgpH9HSCmZ7vR.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Sep 23, 2014, at 3:39 PM, Michael Thomas m...@mtcc.com wrote: On 9/23/14, 1:07 PM, Michael Richardson 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? Do they *have* to participate in the IGP in order for homenet routing to work? 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? Dear Michael, Actually, it is better to assume there is a long list of vulnerable home routers being p0wned by entities beyond their ISP. Leaving that problem aside and assuming this can be handled using a KISS approach, even setting up firewalls when their are multiple routers involved becomes somewhat problematic whenever overlaid networking is not being used. After all, how can each router's assigned prefixes be exchanged. How can mDNS proxy information be communicated? It is important to consider many of the contained devices might be vulnerable to Internet access. Not all devices are updated beyond their warranty period. In some cases, this period might be a 20/20 guarantee, 20 feet or 20 seconds, whichever comes first. While some printers might be able to handle direct Internet access, most can't. Many of these devices announce their routable address via mDNS, hence the need for a network overlay. By using a network overlay, Trust on First Use (TOFU) is less essential although nice to have as an additional layer of protection. Regards, Douglas Otis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Sep 23, 2014, at 7:57 PM, Douglas Otis doug.mtv...@gmail.com wrote: Actually, it is better to assume there is a long list of vulnerable home routers being p0wned by entities beyond their ISP. This is to some extent true, but not something we can really address in homenet. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Fri, 19 Sep 2014, Mark Townsley 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. As far as I can see, there are 2 ways of doing security. Either each protocol does its own security completely (both auth and encryption), or we have generic ways of doing these. The generic ways can be either a new protocol and method, or a method that any protocol can use, so at least the method is standard. What I have seen so far, it seems most implementations are doing things from scratch, but with known methods, but with little code re-use? What I would like to see is an implementation that is generic, but perhaps where the information is carried over a lot of different protocols, for instance HNCP, ND and others. There is no security and zero configuration at the same time. It just doesn't work. I still think we need user intervention to set policy for each device. What trust do I put in this device and what role should it have is something the user has to answer. The result of this answer sets policy for the devices in relation to this new device. This has to be really simple and easy to use. Since a lot of people have smartphones nowadays, I still think that the device popping up in an App they have, and then configuring it there, is the best way. Perhaps in combination with some kind of device key fingerprint using QR codes or alike to really make sure this is the device you're trying to configure policy for. 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. On paper it still seems IPSEC should be able to do this (I mean, isn't this what Microsoft does with Direct Access, ie run IPSEC and have keys handled by AD? From a theoretical level, it seems bad that we can't implement generic security and then let other protocols run on top of that. What is it that IPSEC is lacking? Is it the key/auth exchange that is lacking? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
I agree with this direction. This will also let the work HCNP and Security Threats/Requirements to go on in parallel. Of course, HCNP security may need to be revisited once the latter is agreed upon. Thanks, Acee On 9/21/14, 3:22 PM, Mark Baugher m...@mbaugher.com wrote: On Sep 20, 2014, at 12:57 AM, Steven Barth cy...@openwrt.org wrote: Am 20.09.2014 um 09:17 schrieb Tim Chown: I think it would be useful to do, and needn't hold up progress. It would give us a common understanding - hopefully - of which threats are being covered and which are not. And which are handled by layers/protocols outside the scope of homenet's charter. We started a similar thread about 3 months ago here: http://www.ietf.org/mail-archive/web/homenet/current/msg03694.html maybe this can be used as a starting point. It would be good to limit the scope of HNCP security (the subject of this thread) and consider IETF homenet security in a companion specification that addresses the two differentiators of homenets: Multiple authorities and absence of active management complicate authorization. These differentiators mean there's a different set of problems for authorization than what we ordinarily have in IETF protocols. So HNCP might punt the authorization issue like IETF protocols typically do, e.g. assume in the worst case that an authorized person installs a shared key. But this is not a reasonable assumption in homenets, however, owing to the differences of homenets from enterprise, government, military and other environments where there typically is a single authority and active management of the network. Thus, authorization is an unavoidable topic for Homenet, but the HNCP draft is probably not the place for that. What I'm suggesting is more than a threats or requirements document. Mark Cheers, Steven ___ 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] HNCP security?
On Sep 20, 2014, at 12:57 AM, Steven Barth cy...@openwrt.org wrote: Am 20.09.2014 um 09:17 schrieb Tim Chown: I think it would be useful to do, and needn't hold up progress. It would give us a common understanding - hopefully - of which threats are being covered and which are not. And which are handled by layers/protocols outside the scope of homenet's charter. We started a similar thread about 3 months ago here: http://www.ietf.org/mail-archive/web/homenet/current/msg03694.html maybe this can be used as a starting point. It would be good to limit the scope of HNCP security (the subject of this thread) and consider IETF homenet security in a companion specification that addresses the two differentiators of homenets: Multiple authorities and absence of active management complicate authorization. These differentiators mean there's a different set of problems for authorization than what we ordinarily have in IETF protocols. So HNCP might punt the authorization issue like IETF protocols typically do, e.g. assume in the worst case that an authorized person installs a shared key. But this is not a reasonable assumption in homenets, however, owing to the differences of homenets from enterprise, government, military and other environments where there typically is a single authority and active management of the network. Thus, authorization is an unavoidable topic for Homenet, but the HNCP draft is probably not the place for that. What I'm suggesting is more than a threats or requirements document. Mark Cheers, Steven ___ 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?
On 19 Sep 2014, at 21:59, Ted Lemon mel...@fugue.com wrote: On Sep 19, 2014, at 4:54 PM, Michael Thomas m...@mtcc.com wrote: I guess that's kind of what I've been getting at: should we capture all of this in a threats document? I'm a little uncomfortable with the formality, but I'm even more uncomfortable with the seeming desire by some to sweep this all under the rug. I think it would be worth gathering the information in a document if someone wants to write one, sure. Just talking and not gathering the results is a waste of time. I think there are a fair number of people who have ideas about how this should work. I don't know if a threats document per se is the right thing to do, but a document where this discussion is tracked and recorded would definitely be helpful. It would be a shame though if that effort derailed forward progress, as such things sometimes do. I think it would be useful to do, and needn't hold up progress. It would give us a common understanding - hopefully - of which threats are being covered and which are not. And which are handled by layers/protocols outside the scope of homenet's charter. Tim ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
Am 20.09.2014 um 09:17 schrieb Tim Chown: I think it would be useful to do, and needn't hold up progress. It would give us a common understanding - hopefully - of which threats are being covered and which are not. And which are handled by layers/protocols outside the scope of homenet's charter. We started a similar thread about 3 months ago here: http://www.ietf.org/mail-archive/web/homenet/current/msg03694.html maybe this can be used as a starting point. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Sep 18, 2014, at 12:34 PM, Ted Lemon mel...@fugue.com wrote: On Sep 18, 2014, at 4:27 AM, STARK, BARBARA H bs7...@att.com wrote: UPnP Device Protection uses X.509 certificates (which can be self-signed, and in order not to assume a WAN connection, really should be self-signed) and TLS. I think that something like this, in combination with the promiscuous registration mechanism that I think Michael described earlier, would do the trick. It's not clear that we need X.509 certs, since I have trouble imagining that the keys these devices have would ever be signed by a CA. A bare key might be plenty. But I think this is a better option than trying to shoehorn this functionality into IPsec, which was designed for a _very_ different security context. 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. Another lesson learned was exposing two passwords to the user vs. one. In a retail/wholesale LAC/LNS deployment model, it made perfect sense for the L2TP tunnel to have a password separate from the PPP user password (and L2TP fully supplanted L2F in these types of deployments). But when the L2TP tunnel and the PPP session are are at the same point it just looks redundant to the end user to have separate security config for each (let alone IPsec on top). Knowing the difference between a tail and a dog is important[1], and it was a very bad idea to let the protocol design influence the UI. In retrospect, allowing one protocol to bootstrap the security in another would have been a good thing for us to have considered more. - Mark [1] http://www.urbandictionary.com/define.php?term=the+tail+wagging+the+dog ___ 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?
On 19.9.2014, at 11.18, 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. So DTLS it is? Because I do not want to reinvent any crypto wheels I do not have to. From solution point of view, the only real difference is that DTLS solution cannot be used to secure other protocols between the routers (just with configuration), but I am sure we can stick in some pixie dust PSK TLVs to keep the other protocols’ (bad) security solutions (mostly) functioning. Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Sep 19, 2014, at 3:25 AM, Ted Lemon mel...@fugue.com wrote: On Sep 18, 2014, at 6:46 PM, Mark Baugher m...@mbaugher.com wrote: The retail model works here. I can imagine a compliant CPE might allow the use to take ownership of an interior HNCP interface. That's only if the provider of that CPE wanted to be compliant to a future HNCP security standard. So to be clear, we are now talking about setting up a system where, with HNCP, routers can be anointed by the manufacturer in a registry that ordinary folks wouldn't have access to. No, that's the exact opposite of what I think. It's what I meant to write as ...allow the use[r] to take ownership of the interior HNCP interface. To put it as mildly as possible, I do not support this suggestion: I want home routers to be under the control of the user, not the manufacturer. How could it be otherwise? If you have two service providers in a household, how would one take authority over the other? And what does the manufacturer have to do with it? There might be a device from a third or a other provider/authority in the household. For that reason, it is not realistic to define layer 4 or layer 3 security bindings and then punt on authorization. Unlike enterprise or public networks, there is no single authority with an IT department to insert pre-shared keys in the devices or set up a CA. My suggestion is to start with authorization, because there are potentially multiple owners of the routers, and there needs to be some means for the owner/user of the network to Take Ownership, which is a term used by Walker and Ellison in their home network security work. This has all be designed and implemented before. Mark ___ 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?
On 09/19/2014 01:18 AM, Mark Townsley wrote: Another lesson learned was exposing two passwords to the user vs. one. In a retail/wholesale LAC/LNS deployment model, it made perfect sense for the L2TP tunnel to have a password separate from the PPP user password (and L2TP fully supplanted L2F in these types of deployments). But when the L2TP tunnel and the PPP session are are at the same point it just looks redundant to the end user to have separate security config for each (let alone IPsec on top). Knowing the difference between a tail and a dog is important[1], and it was a very bad idea to let the protocol design influence the UI. In retrospect, allowing one protocol to bootstrap the security in another would have been a good thing for us to have considered more. If we are going to be using a password as the root means of providing authorization to participate in routing or not, we can't use the same password that is used for access control to my network (wpa2), or to another network in your example (ppp, l2tp) or any derived value of it. I don't want my local users or much worse -- my ISP's -- to be able derive a key they already possess for one reason, and be able have at my infrastructure's control plane. Best of all would not to use passwords altogether, cf the zillions of hacks on trivially guessable passwords (MyDoGsPoT). Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
Am 19.09.2014 um 16:00 schrieb Michael Thomas: And it's extremely unlikely that DTLS will be a one-sentence solution even if it gets adopted because DTLS, IPsec, etc say nothing about enrollment and authorization. Those are by far the hard problems with homenent security. I wouldn't really want to lock HNCP to any trust scheme at this point where we are not even sure what we want. I'd rather choose the underlying mechanism, either DTLS or IPsec/IKE and leave the rest out-of-scope. Maybe mention PSK-usage as baseline option and say various other certificate-based approached are possible but out-of-scope of the HNCP draft itself. In practice users could probably run either their own in-home CA (e.g. like draft-behringer-homenet-trust-bootstrap) or we could add a web-of-trust-like extension to HNCP using transitive trust as proposed in draft-bonnetain-hncp-security or some weird combination. Either way it all stands and falls with the final user experience, e.g. the APP and the router's interaction with it for trust-bootstrap or the Web-UI/APP/Push-Button which let's you actively trust your peer in the web-of-trust approach. But user-experience isn't something we can really specify here. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On 09/19/2014 07:52 AM, Steven Barth wrote: Am 19.09.2014 um 16:29 schrieb Michael Thomas: Punting on one of the hardest problems would be a travesty. There are plenty of people in IETF that are plenty smart about this subject; we will never get an opportunity to do the right thing again if we loose this into the wild and say figure it out yourself. We know what happens then. That was not my point. I'm totally happy with having a standardized way of doing this but I don't think that HNCP is the place where it should be defined since we will probably not be the only user. Don't get me wrong if we or anyone else comes up with a brilliant solution I'm all up for referencing it and using it. For HNCP itself what is more important to define in my mind is choosing the crypto-mechanism or at least I would separate those two discussions. HNCP or Homenet in general? Given the possibility of leveraging key distribution and/or auth/authz information from HNCP itself, it might not be bad to consider the homenet security issues organically. However, if this is a plea for kicking this down the road to some non-existent working group, I don't agree at all, and nor do I think that the architecture would permit that. The other point is, it doesn't matter how technically brilliant the solution is in the end if the user experience isn't good enough and that is outside our control really. Adding to that judging from experience with consumer-oriented hardware, if we get HNCP adopted then the baseline of products will probably support no-auth or maybe PSK if we are lucky unless we actually forbid unencrypted HNCP and / or PSK-secured HNCP and I'm not sure I personally would want to go there really. This is the danger of saying later, or even a YOU MUST IMPLEMENT RFC XXX TOO requirement. We've seen this way too many times in the past and it will be a complete mess if don't take a hard line, IMO. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Sep 19, 2014, at 10:52 AM, Steven Barth cy...@openwrt.org wrote: That was not my point. I'm totally happy with having a standardized way of doing this but I don't think that HNCP is the place where it should be defined since we will probably not be the only user. HNCP won't be the only user, but given that it's how the network figures itself out, it's really hard to imagine any other place where the process of arriving at mutual trust could happen. If it's not in HNCP, it's going to be in a different protocol that looks a lot like HNCP, and runs alongside it, sharing a lot of the same per-device state. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Sep 19, 2014, at 8:54 AM, Ted Lemon mel...@fugue.com wrote: On Sep 19, 2014, at 10:52 AM, Steven Barth cy...@openwrt.org wrote: That was not my point. I'm totally happy with having a standardized way of doing this but I don't think that HNCP is the place where it should be defined since we will probably not be the only user. HNCP won't be the only user, but given that it's how the network figures itself out, it's really hard to imagine any other place where the process of arriving at mutual trust could happen. How could it happen? Mark If it's not in HNCP, it's going to be in a different protocol that looks a lot like HNCP, and runs alongside it, sharing a lot of the same per-device state. ___ 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?
On Sep 19, 2014, at 11:59 AM, Mark Baugher m...@mbaugher.com wrote: How could it happen? Isn't that what we've been discussing? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Sep 19, 2014, at 7:17 AM, Steven Barth cy...@openwrt.org wrote: Am 19.09.2014 um 16:00 schrieb Michael Thomas: And it's extremely unlikely that DTLS will be a one-sentence solution even if it gets adopted because DTLS, IPsec, etc say nothing about enrollment and authorization. Those are by far the hard problems with homenent security. I wouldn't really want to lock HNCP to any trust scheme at this point where we are not even sure what we want. I'd rather choose the underlying mechanism, either DTLS or IPsec/IKE and leave the rest out-of-scope. Maybe mention PSK-usage as baseline option and say various other certificate-based approached are possible but out-of-scope of the HNCP draft itself. In practice users could probably run either their own in-home CA (e.g. like draft-behringer-homenet-trust-bootstrap) or we could add a web-of-trust-like extension to HNCP using transitive trust as proposed in draft-bonnetain-hncp-security or some weird combination. Either way it all stands and falls with the final user experience, e.g. the APP and the router's interaction with it for trust-bootstrap or the Web-UI/APP/Push-Button which let's you actively trust your peer in the web-of-trust approach. But user-experience isn't something we can really specify here. Dear Steven, As HNCP is deployed, there should be a sure way to ascertain a home network from that of outside traffic. Wi-Fi Protected Setup (WPS) tried to allow home users an easy way to add new devices to an existing Wi-Fi network without entering long pass-phrases. Making this easy for users, also made compromising the strategy easy for attackers. Will NFC replace that of the vulnerable PIN? Nor can ISP assigned prefixes be shared within a home environment without a sure way to exclude non-local traffic. This should not depend on establishing cryptographic trust methods because this will not prevent users from being deceived; it simply changes what is being unreliably shared. These methods must be bog standard to ensure plumbing works as expected. One such method might attempt to establish an overlay network using the private address space defined for IPv6 and IPv4. Regards, Douglas Otis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
A cert by itself is more or less a wrapper but that¹s not the way PKI works (certs by themselves) - you have certs and trust anchors the anchors being the method by verifying the identity of the person presenting the cert you can do proof of possession as well to very the identity supplicant knows the private key. Randy From: Michael Thomas m...@mtcc.com Date: Thursday, September 18, 2014 at 3:06 PM To: David R Oran daveo...@orandom.net, Rene Struik rstruik@gmail.com Cc: homenet@ietf.org, Markus Stenberg markus.stenb...@iki.fi Subject: Re: [homenet] HNCP security? On 9/18/14, 8:57 AM, David R Oran wrote: On Sep 18, 2014, at 11:46 AM, Rene Struik rstruik@gmail.com mailto:rstruik@gmail.com wrote: It seems that the cryptographic literature needs to be rewritten now ... == Anything you can do with a cert, you can do with raw public keys, and you don't need CA's. See RFC4871 for an example. I would have thought it was the opposite: anything you can do with raw keys you can do with certificates. FWIW, this is also true even though the rest wasn't. You can always strip the x509 coating and use the raw keys, yes. Which begs the question of why use the coating if it's not doing anything useful, which is pretty much the situation with self-signed certs. To paraphrase: 'Some people, when confronted with a security problem, think I know, I'll use certificates. Now they have two problems.' Mike ___ 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?
On Sep 19, 2014, at 1:22 PM, Mark Baugher m...@mbaugher.com wrote: AFAICT, we've been discussing key format or DLTS vs IPsec. That discussion presumes that you have some way for a CPE from ISP-a to securely accept HNCP from ISP-b, or the user's new AP/router, and so forth. How does that happen? Michael Richardson had some suggestions back on the 17th. There's definitely been more talk of keys than mechanisms since then, but that is precisely why I said what I did about the HNCP key discussion. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On 9/19/14, 12:38 PM, Ted Lemon wrote: On Sep 19, 2014, at 1:22 PM, Mark Baugher m...@mbaugher.com wrote: AFAICT, we've been discussing key format or DLTS vs IPsec. That discussion presumes that you have some way for a CPE from ISP-a to securely accept HNCP from ISP-b, or the user's new AP/router, and so forth. How does that happen? Michael Richardson had some suggestions back on the 17th. There's definitely been more talk of keys than mechanisms since then, but that is precisely why I said what I did about the HNCP key discussion. I think the larger implication is that if HNCP has implications of needing to deal with multiple different trust boundaries and how they interact, asking whether we need IPsec or DTLS and then are we done? is profoundly premature. A home network is a vulnerable and very complicated environment even today, and adding a lot more functionality without plumbing the depths of the security implications will only make a bad situation much worse. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Sep 19, 2014, at 4:54 PM, Michael Thomas m...@mtcc.com wrote: I guess that's kind of what I've been getting at: should we capture all of this in a threats document? I'm a little uncomfortable with the formality, but I'm even more uncomfortable with the seeming desire by some to sweep this all under the rug. I think it would be worth gathering the information in a document if someone wants to write one, sure. Just talking and not gathering the results is a waste of time. I think there are a fair number of people who have ideas about how this should work. I don't know if a threats document per se is the right thing to do, but a document where this discussion is tracked and recorded would definitely be helpful. It would be a shame though if that effort derailed forward progress, as such things sometimes do. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Wed, 17 Sep 2014, Michael Thomas wrote: If we were to do that, it might be nice to have a distributed database of homenet devices such that I only had to enroll it on one of my homenet devices, and then it's distributed to the rest. That is exactly what I tried to propose. I agree, if we are going to do define some sort of asymmetric crypto scheme for HNCP, we need to have an automated PKI management. However I don't think this should be a part of HNCP itself but instead a separate protocol. Personally I would probably go with something IPSec-based as main security mechanism for HNCP for now until we have a clear view of how that PKI-scheme and the trust-management should look like taken into account that we have a some special issues here, i.e. how to do revocation if devices potentially don't have network access / an accurate clock at the time of authentication. Also even if we define them I'm not sure as to how much complex PKI-based crypto-schemes will be actually implemented in practice. Regards, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
Just to provide a pointer to a way that another org decided to handle a similar problem (and I'm not suggesting this is the right approach -- I'm just trying to provide food for thought): http://upnp.org/specs/gw/deviceprotection1/ UPnP Device Protection uses X.509 certificates (which can be self-signed, and in order not to assume a WAN connection, really should be self-signed) and TLS. It describes a couple of ways that initial trust and role assignment (what they are authorized to do, once authenticated) can be accomplished. These absolutely need to involve the user. But they need to be as simple as possible. It also describes a mechanism where the list of trusted devices, their keys, and roles (authorizations) can be provided by one device to another. That allows the user to pair a new device with one other device in the network (don't care which), and then be provided the full list of all other such trusted devices, their keys, and roles. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
UPnP Device Protection uses X.509 certificates (which can be self-signed, and in order not to assume a WAN connection, really should be self-signed) and TLS. I think that something like this, in combination with the promiscuous registration mechanism that I think Michael described earlier, would do the trick. It's not clear that we need X.509 certs, since I have trouble imagining that the keys these devices have would ever be signed by a CA. A bare key might be plenty. But I think this is a better option than trying to shoehorn this functionality into IPsec, which was designed for a _very_ different security context. X.509 certificates can be self-signed. That is, the device acts as its own CA. In fact, this is the recommended approach. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Sep 18, 2014, at 7:38 AM, STARK, BARBARA H bs7...@att.com wrote: X.509 certificates can be self-signed. That is, the device acts as its own CA. In fact, this is the recommended approach. Of course. But if there is never going to be a CA-signed key, there is no reason to have a cert at all. Self-signed certs are essentially a way of carrying a bare key in a cert, unless you install your signer key as a CA key, in which case you have an administratively configured CA key that is signing the cert, and it's no longer really a self-signed cert. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On 18.9.2014, at 16.05, Ted Lemon mel...@fugue.com wrote: On Sep 18, 2014, at 7:38 AM, STARK, BARBARA H bs7...@att.com wrote: X.509 certificates can be self-signed. That is, the device acts as its own CA. In fact, this is the recommended approach. Of course. But if there is never going to be a CA-signed key, there is no reason to have a cert at all. Self-signed certs are essentially a way of carrying a bare key in a cert, unless you install your signer key as a CA key, in which case you have an administratively configured CA key that is signing the cert, and it’s no longer really a self-signed cert. On the other hand, use of certificates facilitates also use of something like (hardware bound) device certificates, that would be much harder to generate on demand (and therefore blacklisting them might actually make sense in opportunistic scheme). Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On 09/18/2014 08:31 AM, Markus Stenberg wrote: whether your authorization policy is leap of faithy, or strict ’these are the authorized CAs/individual certs’, there is no way to express same things with raw public keys (or you wind up with new X509, which is in nobody’s best interest). Anything you can do with a cert, you can do with raw public keys, and you don't need CA's. See RFC4871 for an example. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
It seems that the cryptographic literature needs to be rewritten now ... == Anything you can do with a cert, you can do with raw public keys, and you don't need CA's. See RFC4871 for an example. On 9/18/2014 11:36 AM, Michael Thomas wrote: On 09/18/2014 08:31 AM, Markus Stenberg wrote: whether your authorization policy is leap of faithy, or strict ’these are the authorized CAs/individual certs’, there is no way to express same things with raw public keys (or you wind up with new X509, which is in nobody’s best interest). Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- email: rstruik@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Sep 18, 2014, at 11:46 AM, Rene Struik rstruik@gmail.com wrote: It seems that the cryptographic literature needs to be rewritten now ... == Anything you can do with a cert, you can do with raw public keys, and you don't need CA's. See RFC4871 for an example. I would have thought it was the opposite: anything you can do with raw keys you can do with certificates. Raw keys cannot prove an assertion that a certain claimed name is bound to a certain key. In the case of self-signed certs you only get the advantages of having a data structure and code that is understood and well vetted, but with either a PKI or a web of trust you do get benefits from using Certs. You also get usage policy restrictions, which cannot be expressed with raw keys. On 9/18/2014 11:36 AM, Michael Thomas wrote: On 09/18/2014 08:31 AM, Markus Stenberg wrote: whether your authorization policy is leap of faithy, or strict ’these are the authorized CAs/individual certs’, there is no way to express same things with raw public keys (or you wind up with new X509, which is in nobody’s best interest). Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- email: rstruik@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 ___ 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?
On 9/18/14, 8:57 AM, David R Oran wrote: On Sep 18, 2014, at 11:46 AM, Rene Struik rstruik@gmail.com wrote: It seems that the cryptographic literature needs to be rewritten now ... == Anything you can do with a cert, you can do with raw public keys, and you don't need CA's. See RFC4871 for an example. I would have thought it was the opposite: anything you can do with raw keys you can do with certificates. FWIW, this is also true even though the rest wasn't. You can always strip the x509 coating and use the raw keys, yes. Which begs the question of why use the coating if it's not doing anything useful, which is pretty much the situation with self-signed certs. To paraphrase: 'Some people, when confronted with a security problem, think I know, I'll use certificates. Now they have two problems.' Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
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
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 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Sep 18, 2014, at 8:57 AM, David R Oran daveo...@orandom.net wrote: On Sep 18, 2014, at 11:46 AM, Rene Struik rstruik@gmail.com wrote: It seems that the cryptographic literature needs to be rewritten now ... == Anything you can do with a cert, you can do with raw public keys, and you don't need CA's. See RFC4871 for an example. I would have thought it was the opposite: anything you can do with raw keys you can do with certificates. Raw keys cannot prove an assertion that a certain claimed name is bound to a certain key. In the case of self-signed certs you only get the advantages of having a data structure and code that is understood and well vetted, but with either a PKI or a web of trust you do get benefits from using Certs. You also get usage policy restrictions, which cannot be expressed with raw keys. Agreed and this whole discussion is deju vu all over again for me, and no longer very interesting. What's more important than the container is how keys come to get authorized or rejected, what authorization means and how to revoke it, do an on-line test, etc. As someone on this thread has asked: Has any of this been written down? Requirements, use cases, threat analysis should all help to inform our decision about what format to use. Mark On 9/18/2014 11:36 AM, Michael Thomas wrote: On 09/18/2014 08:31 AM, Markus Stenberg wrote: whether your authorization policy is leap of faithy, or strict ’these are the authorized CAs/individual certs’, there is no way to express same things with raw public keys (or you wind up with new X509, which is in nobody’s best interest). Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- email: rstruik@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 ___ 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] HNCP security?
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
Re: [homenet] HNCP security?
On Sep 18, 2014, at 2:37 PM, Randy Turner rtur...@amalfisystems.com wrote: How do you bootstrap trust relationships without an initial certificate (whether installed at manufacturing or during a customer fulfillment stage) ? One way is through a user security ceremony (viz. Walker and Ellison) in the Wi-Fi and UPnP standards: The user pushes a recites a password, pushes buttons, waves an NFC device, etc. to authorize, e.g. sign the router's self-signed cert so other routers will accept its HNCP. That's a root of trust model. I'm sure there are other such models. There's been some talk about using web of trust, but I don't understand how that would work. Mark Original message From: Michael Thomas m...@mtcc.com Date:09/18/2014 4:17 PM (GMT-06:00) To: homenet@ietf.org 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 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] HNCP security?
On 19/09/2014 09:17, Michael Thomas wrote: 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. Surely they are of help for secure *identification* of devices? Authorisation is a separate step. 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. Yes, but with the identity of the devices verified by cert. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
Are we assuming that the home router is purchased retail, and not fulfilled or provided by an ISP? The method to establish trust relationships would hinge on the answer Randy Original message From: Mark Baugher m...@mbaugher.com Date:09/18/2014 5:12 PM (GMT-06:00) To: Randy Turner rtur...@amalfisystems.com Cc: homenet@ietf.org Group homenet@ietf.org Subject: Re: [homenet] HNCP security? On Sep 18, 2014, at 2:37 PM, Randy Turner rtur...@amalfisystems.com wrote: How do you bootstrap trust relationships without an initial certificate (whether installed at manufacturing or during a customer fulfillment stage) ? One way is through a user security ceremony (viz. Walker and Ellison) in the Wi-Fi and UPnP standards: The user pushes a recites a password, pushes buttons, waves an NFC device, etc. to authorize, e.g. sign the router's self-signed cert so other routers will accept its HNCP. That's a root of trust model. I'm sure there are other such models. There's been some talk about using web of trust, but I don't understand how that would work. Mark Original message From: Michael Thomas m...@mtcc.com Date:09/18/2014 4:17 PM (GMT-06:00) To: homenet@ietf.org 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 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] HNCP security?
On 9/18/14, 3:39 PM, Brian E Carpenter wrote: Yes, I agree and that's why self-signed and/or manufacturer certs are of no help. Surely they are of help for secure *identification* of devices? No more so than the naked public key. Authorisation is a separate step. Yes. 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. Yes, but with the identity of the devices verified by cert. A cert, at its heart, is used to bind a name (CN, DN, etc) to a key. You don't need a human friendly name binding to identify something that possesses the corresponding private key though. The public key itself is a unique identifier. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
The retail model works here. I can imagine a compliant CPE might allow the use to take ownership of an interior HNCP interface. That's only if the provider of that CPE wanted to be compliant to a future HNCP security standard. Mark On Sep 18, 2014, at 3:43 PM, Randy Turner rtur...@amalfisystems.com wrote: Are we assuming that the home router is purchased retail, and not fulfilled or provided by an ISP? The method to establish trust relationships would hinge on the answer Randy Original message From: Mark Baugher m...@mbaugher.com Date:09/18/2014 5:12 PM (GMT-06:00) To: Randy Turner rtur...@amalfisystems.com Cc: homenet@ietf.org Group homenet@ietf.org Subject: Re: [homenet] HNCP security? On Sep 18, 2014, at 2:37 PM, Randy Turner rtur...@amalfisystems.com wrote: How do you bootstrap trust relationships without an initial certificate (whether installed at manufacturing or during a customer fulfillment stage) ? One way is through a user security ceremony (viz. Walker and Ellison) in the Wi-Fi and UPnP standards: The user pushes a recites a password, pushes buttons, waves an NFC device, etc. to authorize, e.g. sign the router's self-signed cert so other routers will accept its HNCP. That's a root of trust model. I'm sure there are other such models. There's been some talk about using web of trust, but I don't understand how that would work. Mark Original message From: Michael Thomas m...@mtcc.com Date:09/18/2014 4:17 PM (GMT-06:00) To: homenet@ietf.org 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 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] HNCP security?
On 9/18/14, 3:43 PM, Randy Turner wrote: Are we assuming that the home router is purchased retail, and not fulfilled or provided by an ISP? The method to establish trust relationships would hinge on the answer I should be able prepurpose an old PC with linux running homenet software. We can make no assumptions about where my PC came from initially. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
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 bs7...@att.com Date:09/18/2014 5:02 PM (GMT-06:00) To: Randy Turner rtur...@amalfisystems.com, Michael Thomas m...@mtcc.com, homenet@ietf.org 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 m...@mtcc.com Date:09/18/2014 4:17 PM (GMT-06:00) To: homenet@ietf.org 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 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?
On Tue, 16 Sep 2014, Tim Chown wrote: There’s obviously some interesting implications of this. One is that there are insecure wired links too! Good point. I believe we're hitting the classic secure or easy tradeoff. There is no way we automatically can detect what is home and what is not, instead there is going to have to be user interaction to say what is part of the home and what is not. For HNCP, this might mean some kind of cryptographic interaction of some kind, for instance what you suggested, having some kind of button, or perhaps having some kind of home control panel where new devices pop up and where they're authorized (or not). As was presented in.. err, London?, shared secrets are bad. To really do this properly, we need device specific keys and some kind of list of devices that are allowed to connect, perhaps by having their public keys in HNCP. I don't know. I am no security expert, but I believe we probably have to have two or three modes of security, one being unsecure that is auto everything (will give scenarios like the one Tim wrote about), one that is shared secret, but where devices need to be configured using this shared secret (protects against accidents), and a third one where PKI is used, but where user policy infrastructure is available. The third one greatly increases scope the framework required to implement. I'm not sure it would even be HNCP anymore, perhaps we need a wider view than what the HOMENET charter has in it currently. It wouldn't surprise me if we need another WG to tackle this. Perhaps it should be a more generic one based on creating a framework to handle access requests and control and how to distribute keys and other credentials, for SSH/SSL/IPSEC use, potentially? A lot of these mechanisms probably already exists, but they need to be put together and told how to interact. -- Mikael Abrahamssonemail: swm...@swm.pp.se___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
Tim Chown t...@ecs.soton.ac.uk wrote: On 16 Sep 2014, at 14:52, Michael Richardson mcr+i...@sandelman.ca wrote: I think that we can assume that wired links are secure. The only time we care if wireless is secured is when we want to form an adjacency over the wireless link. I think it is acceptable to refuse to form an adjancency over an insecured wireless link. A little side story… ... To cut a long story short, my powerline adaptors had formed a single network with powerline adaptors in a neighbour’s house. Yes, this is an issue, and you could equally have done this over cable modem. Or if you plugged a layer-2 ethernet/802.11 extender in to a wired port of your router, and your neighbour did the same thing. It's always possible to defeat things; the question is whether or not your 1% situation should mean that we have no security for 99% of the other times it works fine? That's why I suggest that the wire permits a TOFU bootstrap, not that it's forever insecure. I don't see how your buttons, etc. would have permitted anything, since that would have been about the wifi. My understanding is that a new generation of powerline ethernet now actually uses 15.4 MACs with a different PHY, and in fact runs Zigbee over it, for exactly the situation you mentioned. -- ] 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
Re: [homenet] HNCP security?
On 09/17/2014 06:37 AM, Michael Richardson wrote: Michael Thomas m...@mtcc.com wrote: I further suggest that if two routers have wireless that they might well have a WPA2/PSK available to them, and that they can and SHOULD use something derived from that key to authenticate each other. Could be over IKEv2, yes. If I have more than one SSID, which PSK should the router use? Whichever ones authenticates the message. The PSK is not transmitted. I'm about to send a routing update, or whatever message. Which WPA2 key does the router use? And if it's a simple derivation, that means that anybody with the right PSK can derive that key and participate in routing whether we want them to or not, right? That is, where is the authz? That's the nature of a PSK, yes. I want to control people who I give access to my home network to participate in routing or not. Overloading network access control with access to control plane modification sounds like a bad idea to me. If you wanted to overload the use of a key, it might better to derive a key from their admin logins. But it would be best of all to not overload anything. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On 09/16/2014 11:31 PM, Mikael Abrahamsson wrote: As was presented in.. err, London?, shared secrets are bad. To really do this properly, we need device specific keys and some kind of list of devices that are allowed to connect, perhaps by having their public keys in HNCP. I don't know. I am no security expert, but I believe we probably have to have two or three modes of security, one being unsecure that is auto everything (will give scenarios like the one Tim wrote about), one that is shared secret, but where devices need to be configured using this shared secret (protects against accidents), and a third one where PKI is used, but where user policy infrastructure is available. The third one greatly increases scope the framework required to implement. I'm not sure it would even be HNCP anymore, perhaps we need a wider view than what the HOMENET charter has in it currently. Global symmetric keys certainly have their problems, but using public keys have their own. Namely, if I want to enroll a new device each other currently enrolled device needs to know about the public key of the new enrollee. For 2 devices, that's possibly manageable but for more I really don't want to run around my house looking for every homenet device to enroll the new one. If we were to do that, it might be nice to have a distributed database of homenet devices such that I only had to enroll it on one of my homenet devices, and then it's distributed to the rest. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On 9/17/14, 10:24 AM, Michael Richardson wrote: Michael Thomas m...@mtcc.com wrote: If I have more than one SSID, which PSK should the router use? Whichever ones authenticates the message. The PSK is not transmitted. I'm about to send a routing update, or whatever message. Which WPA2 key does the router use? You don't use that key for that. You use a key that IKEv2 built for you, using that key to authenticate the IKEv2 session. The result shows up in a list of peers, if you have turned off TOFU, then you'd have to authorize each one. Which is that key here? I thought you said previously that that key was somehow derived from a WPA2 PSK. If not, I don't understand how IKE helps with the enrollment problem. References to TOFU would be appreciated too... google is not immediately helpful. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On 18/09/2014 02:58, Michael Thomas wrote: On 09/16/2014 11:31 PM, Mikael Abrahamsson wrote: As was presented in.. err, London?, shared secrets are bad. To really do this properly, we need device specific keys and some kind of list of devices that are allowed to connect, perhaps by having their public keys in HNCP. I don't know. I am no security expert, but I believe we probably have to have two or three modes of security, one being unsecure that is auto everything (will give scenarios like the one Tim wrote about), one that is shared secret, but where devices need to be configured using this shared secret (protects against accidents), and a third one where PKI is used, but where user policy infrastructure is available. The third one greatly increases scope the framework required to implement. I'm not sure it would even be HNCP anymore, perhaps we need a wider view than what the HOMENET charter has in it currently. Global symmetric keys certainly have their problems, but using public keys have their own. Namely, if I want to enroll a new device each other currently enrolled device needs to know about the public key of the new enrollee. For 2 devices, that's possibly manageable but for more I really don't want to run around my house looking for every homenet device to enroll the new one. If we were to do that, it might be nice to have a distributed database of homenet devices such that I only had to enroll it on one of my homenet devices, and then it's distributed to the rest. I don't think that's a nice to have. I think it's an unavoidable requirement, and it has to require at most trivial human intervention. (Don't shoot me, but this happens to be a must-have for autonomic networking too.) Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Wed, 17 Sep 2014, Michael Thomas wrote: Global symmetric keys certainly have their problems, but using public keys have their own. Namely, if I want to enroll a new device each other currently enrolled device needs to know about the public key of the new enrollee. For 2 devices, that's possibly manageable but for more I really don't want to run around my house looking for every homenet device to enroll the new one. If we were to do that, it might be nice to have a distributed database of homenet devices such that I only had to enroll it on one of my homenet devices, and then it's distributed to the rest. That is exactly what I tried to propose. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
Michael Thomas m...@mtcc.com wrote: I'm pretty certain that the answer to this is going to be no. does zigbee even have link layer crypto, for example? and even if it does, new ones as they come on line are likely to have flaws for a long time (cf wifi). zigbeeIP mandates link layer crypto, but it's a non-sequitor, because HNCP would run up to the ethernet/zigbee boundary, but not beyond it. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- pgp2o0JozrGXn.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
Markus Stenberg markus.stenb...@iki.fi wrote: markus What the draft does not cover is what is the assumption about markus security of protocols within it. If HNCP is run only over either markus physically or cryptographically secured link layer, there are no markus real extra requirements for HNCP. markus So, question time: markus 1) Can we assume secure L2 and/or appropriate device markus configuration by the manufacturer/ISP(/user)? (This is what I can markus assume in my own home.) I think that we can assume that wired links are secure. The only time we care if wireless is secured is when we want to form an adjacency over the wireless link. I think it is acceptable to refuse to form an adjancency over an insecured wireless link. I think it is acceptable to do some kind of TOFU (using IPsec with IKEv2 even) point to point across wired links, and having done that, if there is an adjancy later possible between those two devices over what would otherwise be an insecure link, that the previously exchanged keys work. That means one can plug two routers together with a cable, and then separate them, knowning that the two routers will remain entangled (I'm making allusions to http://en.m.wikipedia.org/wiki/Quantum_entanglement) I further suggest that if two routers have wireless that they might well have a WPA2/PSK available to them, and that they can and SHOULD use something derived from that key to authenticate each other. Could be over IKEv2, yes. markus 2) If not, should the solution be some sort of pre-shared key markus scheme? (If not, please explain your alternative solution.) If we assume the abovekey, we could use it to derive a pre-shared key for a multicast IPsec SA using AH. Can we assume, declare, that if you don't know the key, that you skip the AH header, and process the HNCP that is inside as if it wasn't secured at all? We wanted to do that for SEND, but there were IPsec implementations that could do that, because we overspecified AH back in 2401. Given that home routers are purpose built boxes, and not generic random hosts, perhaps we can specify this behaviour. markus 2.1) And if so, should it be manually keyed IPsec (multicast markus prevents e.g. IKE)? (This is what is in the draft currently.) Yes, if we can make this AH assumption of skipping, so that we can get TOFU to work. markus 2.2) Or should we roll our own in-HNCP scheme? No. I realize that there is an issue with cable modems and FTTH systems such that the ISP boundary can be hard to recognize. I propose that HNCP use scope-5 multicast, and that we try to convince the Broadband forum that it's cable modems should drop scope-5 multicast, if they see it. Further, we have the heuristic that if we saw DHCPv6PD on that interface, it might be an ISP. (If we also saw DHCPv6PD, and we saw authenticated HNCP, then it is internal) -- ] 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[ -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- pgpqn07qm0khx.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On 16 Sep 2014, at 14:52, Michael Richardson mcr+i...@sandelman.ca wrote: I think that we can assume that wired links are secure. The only time we care if wireless is secured is when we want to form an adjacency over the wireless link. I think it is acceptable to refuse to form an adjancency over an insecured wireless link. A little side story… I have an old house with quite thick walls. Standard 802.11 doesn't reach all rooms. Not that long ago I bought a pair of Netgear powerline Ethernet adaptors to extend coverage between rooms. I’d used an older version before, and it worked well, giving more throughout than the wireless and with the extended range. The interesting thing was that soon after plugging them in I noticed I’d lost connectivity on a laptop, and my desktop was behaving oddly. I looked at the network config to remind myself of the IP address of my default ADSL router. I used a browser to connect to the default router by IP to check its configuration. And got quite a surprise as it was a Sky router - a surprise as I’m not a customer of theirs! To cut a long story short, my powerline adaptors had formed a single network with powerline adaptors in a neighbour’s house. At which point my devices were getting responses from two DHCP servers, and some were routing out via the neighbour’s router. And that included some of my wireless devices - no point having WPA2 to protect against unwanted ‘guests’ if they can come in a power line Ethernet back door :) Now, what I should have done, but it’s easy to get distracted and forget(!), was use the magic ‘auto configure a shared secret’ button on each of my adaptors to avoid them merging with my neighbour’s devices, or manually configure shared secrets (yuk). But clearly neither of us had done that. The interesting thing was I could see the neighbour’s SSID from their Sky router splash screen, but having walked around the nearest streets, I couldn’t find it. I wonder how far away that house was... There’s obviously some interesting implications of this. One is that there are insecure wired links too! Tim ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Sep 16, 2014, at 1:29 PM, Tim Chown t...@ecs.soton.ac.uk wrote: There’s obviously some interesting implications of this. One is that there are insecure wired links too! That's a good point. And I wonder about malware on end systems as well. Mark ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
Hello everyone, 1) Can we assume secure L2 and/or appropriate device configuration by the manufacturer/ISP(/user)? (This is what I can assume in my own home.) I think secure L2 is not enough for HNCP (and routing protocol) security. *Assuming* we have it, either we allow any connected device to ‘speak’ HNCP, or we require the user to configure authorized neighbors, at the L2 layer, which would be way too complex because of the variety of L2 technologies. The problem is that I wouldn’t want any connected device to be able to participate in HNCP. L2 access is not the same as HNCP authorization. Routers are easier to secure than cloud-based IOT devices, so I would rather introduce a way of filtering authorized HNCP devices. 2) If not, should the solution be some sort of pre-shared key scheme? (If not, please explain your alternative solution.) It’s a possibility. I would like to mention this proposal from last IETF: http://tools.ietf.org/html/draft-bonnetain-hncp-security-00 . Not saying it is *the* solution, but an alternative to the PSK relaying on asymmetric crypto. In general, HNCP also needs to bootstrap the routing protocol. So I think HNCP would require some way to share secondary keys (If not the same as the primary), in order to bootstrap other protocol’s security. Cheers, - Pierre ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On 13.9.2014, at 20.27, Michael Thomas m...@mtcc.com wrote: I think we should be clear that hijacking router-router traffic brings a whole new class of breaches that home networks are probably not particularly susceptible to today. An active man in the middle is a very bad thing and that seems trivially doable without some precautions. Today most home networks are simply bridged, and you can do active MITM there well enough (hello, ARP spoofing), unless it is protected against. And most home routers don’t protect against it as bridging is done on simple ASIC. This is yet another reason why I keep saying that the goal should be littleconf rather than “zeroconf. I prefer idea of littleconf personally too; I wonder what that ‘conf’ is is. Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On 13.9.2014, at 23.30, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 13/09/2014 17:40, Markus Stenberg wrote: 1) Can we assume secure L2 and/or appropriate device configuration by the manufacturer/ISP(/user)? (This is what I can assume in my own home.) I'm not sure I fully understand this question, but certainly there a vast numbers of insecure home 802.11 setups. This is less prevalent than it was a few years ago, but it seems like a dangerous assumption if homenet-compliant kit is mixed in with older stuff such as wireless hubs that are open by default. From my point of view, if you’re exposing part of your home network via insecure wireless, only way to secure it would be to run mandatory crypto over it both to hosts and routers. I’m not sure this is really feasible either. Just securing router-router traffic (or parts of it) does not bring significant benefit from my point of view unless you also authenticate hosts in such a case. All true (as are the subsequent comments by Acee and Michael). But the fact remains that we can't assume L2 is secure in the normal case, which is a much worse situation than we traditionally assumed for wired networks. Ok, so your stance is that we can’t assume secure L2, but neither can we do anything useful without fully encrypted traffic. As fully encrypted traffic is not an option (computational overhead, not-so-littleconf on routers and probably impossible on current hosts), what, exactly, do you propose then? Not deploy routed home networks at all until we can assume L2 security? Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
Brian, et al, L2 never really was secure, regardless of whether we are talking about enterprise or home networks, wired or wireless. Sure there was a firewall in place, but the L2 and the subnet behind the firewall was only as secure as the least secure device that ever connected to it. Which is to say, not at all secure. I have yet to work at a corporation since the mid-1990s that didn't at some point have IT report that the local network was clogged due to a virus run rampant behind the firewall. This has always applied to both wired and wireless networks. Perhaps it is worse with wireless since any laptop or cell phone able to connect is a potential breach that can be leveraged if L2 security is assumed. [So I'm agreeing with Brian, but pointing out that wired L2 was never secure in the first place.] Curtis In message 5414a96c.2050...@gmail.com Brian E Carpenter writes: On 13/09/2014 17:40, Markus Stenberg wrote: On 13.9.2014, at 5.50, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 12/09/2014 22:23, Markus Stenberg wrote: ... 1) Can we assume secure L2 and/or appropriate device configuration by the manufacturer/ISP(/user)? (This is what I can assume in my own home.) I'm not sure I fully understand this question, but certainly there a vast numbers of insecure home 802.11 setups. This is less prevalent than it was a few years ago, but it seems like a dangerous assumption if homenet-compliant kit is mixed in with older stuff such as wireless hubs that are open by default. From my point of view, if youâre exposing part of your home network via insecure wireless, only way to secure it would be to run mandatory crypto over it both to hosts and routers. Iâm not sure this is really feasible either. Just securing router-router traffic (or parts of it) does not bring significant benefit from my point of view unless you also authenticate hosts in such a case. All true (as are the subsequent comments by Acee and Michael). But the fact remains that we can't assume L2 is secure in the normal case, which is a much worse situation than we traditionally assumed for wired networks. Brian While securing HNCP in such a case would prevent some attacks on in-home network auto-configuration, anything else (e.g. using home resources, using home internet access, pretending to be uplink and performing MITM, the list goes on) would be still possible and I do not see the point. Cheers, -Markus. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On 14.9.2014, at 17.48, Michael Thomas m...@mtcc.com wrote: On 09/14/2014 02:04 AM, Markus Stenberg wrote: On 13.9.2014, at 23.30, Brian E Carpenter brian.e.carpen...@gmail.com wrote: All true (as are the subsequent comments by Acee and Michael). But the fact remains that we can't assume L2 is secure in the normal case, which is a much worse situation than we traditionally assumed for wired networks. Ok, so your stance is that we can’t assume secure L2, but neither can we do anything useful without fully encrypted traffic. As fully encrypted traffic is not an option (computational overhead, not-so-littleconf on routers and probably impossible on current hosts), what, exactly, do you propose then? Not deploy routed home networks at all until we can assume L2 security? I think you're throwing up your hands way too prematurely. I don't know what fully encrypted traffic means in this context. If you're talking about the router-router signaling traffic itself (eg, ospf), symmetric crypto (eg, aes+sha256 -- note all you might need is just integrity too) adds trivial process load these days. Public key operations are similarly a drop in the bucket these days when used sparingly (eg, for enrollment, session establishment, etc). Modern router boxes are not microvax 1's with two fat ethernet ports, after all. Like I stated earlier in my email, if you do not assume secure L2, just securing router-to-router traffic does little to protect the homenet. Quote: … anything else (e.g. using home resources, using home internet access, pretending to be uplink and performing MITM, the list goes on) would be still possible and I do not see the point. Also, if we assume the home user does not bother to set up L2 security for their home infra (notably wireless), what are the odds they set up HNCP in a secure manner? I wouldn’t bet on it. Also: I think that HNCP needs to take care of HNCP and not worry about boiling the homenet security ocean. Even if we end up with layers of crypto via L2. That's ok. Last, without actually knowing what threats/attacks we're trying to defend against, it's *way* to early to say how much configuration might be required. Remember: WPA2 requires the input of exactly one passphrase per SSID. That is manifestly not an insurmountable burden. And that's just for starters: we may be able to get away with leap of faith kinds of enrollment depending on the threats which may require minimal user intervention (eg: “should I do this, Y|n”). Well, please write up on how you think this could be ‘easily’, without some sort of magic provisioning/hardware that cannot be assumed to be always available. (For example, Apple does nice enough user experience for configuring Airport stuff, but it works nicely if and only if both your hosts and routers are from same vendor. Not applicable here.) So the real job here is to consider what the threats are first and foremost before making blanket statements about l2, l3, processor speed, etc, etc. Certainly. Routers themselves (regardless of what protocol traffic they are sending) as _endpoints_ of traffic constitute only minor part of attack surface of your typical home network. Let’s consider the parties involved: upstream router on ISP side - no crypto with them in typical case for foreseeable future home routers - ok, fine, we can probably do something about them hosts - cannot assume really crypto, except maybe L2 (e.g. WPA2 or even less likely 802.1x/MACSec) Here’s few threats and how to mitigate them from the last IETF slides (http://www.ietf.org/proceedings/90/slides/slides-90-homenet-8.pdf slide 3): 1. fake ISP (= active MITM, active packet snooping) As upstream router isn’t authenticated (DHCPv6 + RAs indicate it is an upstream router, nothing else), only littleconf about where upstream routers can appear protects from this. (and-or fictional DHCPv6 authentication using ISPs.) 2. access to home resources (~DoS, unprivileged access) As hosts are not authenticated (if we can’t assume secure L2 of some kind), nothing to be done here. 3. someone actively mutating in-home routing state (= active MITM, DoS) Yes, this could be addressed by just securing router-to-router traffic. [1]/[2] are not affected by _any_ magic you throw in HNCP, and it presents exactly same threats and more besides what is in [3]. Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On 09/14/2014 09:38 AM, Markus Stenberg wrote: Like I stated earlier in my email, if you do not assume secure L2, just securing router-to-router traffic does little to protect the homenet. The subject line says HNCP security, so I naively thought that's what this was about. So the real job here is to consider what the threats are first and foremost before making blanket statements about l2, l3, processor speed, etc, etc. Certainly. Routers themselves (regardless of what protocol traffic they are sending) as _endpoints_ of traffic constitute only minor part of attack surface of your typical home network. Let’s consider the parties involved: upstream router on ISP side - no crypto with them in typical case for foreseeable future home routers - ok, fine, we can probably do something about them hosts - cannot assume really crypto, except maybe L2 (e.g. WPA2 or even less likely 802.1x/MACSec) As a meta point: crypto != security. Here’s few threats and how to mitigate them from the last IETF slides (http://www.ietf.org/proceedings/90/slides/slides-90-homenet-8.pdf slide 3): 1. fake ISP (= active MITM, active packet snooping) As upstream router isn’t authenticated (DHCPv6 + RAs indicate it is an upstream router, nothing else), only littleconf about where upstream routers can appear protects from this. (and-or fictional DHCPv6 authentication using ISPs.) Is this a threat to HNCP? I thought that HNCP was an IGP? 2. access to home resources (~DoS, unprivileged access) As hosts are not authenticated (if we can’t assume secure L2 of some kind), nothing to be done here. Not an HNCP threat? 3. someone actively mutating in-home routing state (= active MITM, DoS) Definitely an HNCP threat. Seems like you might want to have some sort of auth/authz, but it's hard to know exactly what because I don't understand the expected enrollment model. Is that all? Maybe we can recycle security threats from OSPF, etc for a more comprehensive list? Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On 15/09/2014 03:59, Curtis Villamizar wrote: Brian, et al, L2 never really was secure, regardless of whether we are talking about enterprise or home networks, wired or wireless. Sure there was a firewall in place, but the L2 and the subnet behind the firewall was only as secure as the least secure device that ever connected to it. Which is to say, not at all secure. I have yet to work at a corporation since the mid-1990s that didn't at some point have IT report that the local network was clogged due to a virus run rampant behind the firewall. This has always applied to both wired and wireless networks. Perhaps it is worse with wireless since any laptop or cell phone able to connect is a potential breach that can be leveraged if L2 security is assumed. Precisely. Security is in reality always a relative term, and a network is roughly as secure as its least secure component. The point is that a non-secured 802.11 network welcomes MITM, so HNCP in particular needs to resist MITM (unless you are happy if the small print on the box warns against running non-secured 802.11). I don't think that MITM-resistance requires encryption, though - authenticated identity should be enough. Homenet in general needs to worry about DOS and surveillance allowed by weak L2 security, but that's a separate topic. Brian [So I'm agreeing with Brian, but pointing out that wired L2 was never secure in the first place.] Curtis In message 5414a96c.2050...@gmail.com Brian E Carpenter writes: On 13/09/2014 17:40, Markus Stenberg wrote: On 13.9.2014, at 5.50, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 12/09/2014 22:23, Markus Stenberg wrote: ... 1) Can we assume secure L2 and/or appropriate device configuration by the manufacturer/ISP(/user)? (This is what I can assume in my own home.) I'm not sure I fully understand this question, but certainly there a vast numbers of insecure home 802.11 setups. This is less prevalent than it was a few years ago, but it seems like a dangerous assumption if homenet-compliant kit is mixed in with older stuff such as wireless hubs that are open by default. From my point of view, if you’re exposing part of your home network via insecure wireless, only way to secure it would be to run mandatory crypto over it both to hosts and routers. I’m not sure this is really feasible either. Just securing router-router traffic (or parts of it) does not bring significant benefit from my point of view unless you also authenticate hosts in such a case. All true (as are the subsequent comments by Acee and Michael). But the fact remains that we can't assume L2 is secure in the normal case, which is a much worse situation than we traditionally assumed for wired networks. Brian While securing HNCP in such a case would prevent some attacks on in-home network auto-configuration, anything else (e.g. using home resources, using home internet access, pretending to be uplink and performing MITM, the list goes on) would be still possible and I do not see the point. Cheers, -Markus. . ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
I agree with Markus. The conflicting goals of self-configuration and security seem to be a recurring theme in homenet. I reread the security section in the ³Homenet Architecture² and it mainly covers with security at the edges (which presumes effective edge detection). There is this statement regarding the internal homenet: 3.6.4. Exfiltration concerns As homenets become more complex, with more devices, and with service discovery potentially enabled across the whole home, there are potential concerns over the leakage of information should devices use discovery protocols to gather information and report it to equipment vendors or application service providers. While it is not clear how such exfiltration could be easily avoided, the threat should be recognised, be it from a new piece of hardware or some 'app' installed on a personal device. This is definitely something we¹ll need to come to terms with to move forward and there may be more than one model. Thanks, Acee On 9/13/14, 1:40 AM, Markus Stenberg markus.stenb...@iki.fi wrote: On 13.9.2014, at 5.50, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 12/09/2014 22:23, Markus Stenberg wrote: ... 1) Can we assume secure L2 and/or appropriate device configuration by the manufacturer/ISP(/user)? (This is what I can assume in my own home.) I'm not sure I fully understand this question, but certainly there a vast numbers of insecure home 802.11 setups. This is less prevalent than it was a few years ago, but it seems like a dangerous assumption if homenet-compliant kit is mixed in with older stuff such as wireless hubs that are open by default. From my point of view, if you¹re exposing part of your home network via insecure wireless, only way to secure it would be to run mandatory crypto over it both to hosts and routers. I¹m not sure this is really feasible either. Just securing router-router traffic (or parts of it) does not bring significant benefit from my point of view unless you also authenticate hosts in such a case. While securing HNCP in such a case would prevent some attacks on in-home network auto-configuration, anything else (e.g. using home resources, using home internet access, pretending to be uplink and performing MITM, the list goes on) would be still possible and I do not see the point. Cheers, -Markus ___ 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?
On 09/13/2014 10:16 AM, Acee Lindem (acee) wrote: I agree with Markus. The conflicting goals of self-configuration and security seem to be a recurring theme in homenet. I reread the security section in the ³Homenet Architecture² and it mainly covers with security at the edges (which presumes effective edge detection). There is this statement regarding the internal homenet: 3.6.4. Exfiltration concerns As homenets become more complex, with more devices, and with service discovery potentially enabled across the whole home, there are potential concerns over the leakage of information should devices use discovery protocols to gather information and report it to equipment vendors or application service providers. While it is not clear how such exfiltration could be easily avoided, the threat should be recognised, be it from a new piece of hardware or some 'app' installed on a personal device. This is definitely something we¹ll need to come to terms with to move forward and there may be more than one model. I think we should be clear that hijacking router-router traffic brings a whole new class of breaches that home networks are probably not particularly susceptible to today. An active man in the middle is a very bad thing and that seems trivially doable without some precautions. This is yet another reason why I keep saying that the goal should be littleconf rather than zeroconf. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
