Re: [homenet] hncp-security-trust
I assume that the trust verdicts would be distributed by hncp, but the documenet doesn't seem to say so. Yes, they are. The idea was too limit them in some way since neutral verdicts can be created by (unusuccessful) external connection attempts and thus it must be avoided that established node's node data is cluttered with too many neutral verdicts over time. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] hncp-security-trust
section 6.3.3 contemplates sending out verdicts for a period of time until a decision can be rendered, giving up after 10 minutes. I think, that since hncp is using trickle, it can just rely on trickle saying that we haven't got any new information, so just don't say anything. I assume that the trust verdicts would be distributed by hncp, but the documenet doesn't seem to say so. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- pgpqEJ_mDG37I.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-barth-homenet-hncp-security-trust-01.txt
On 10/22/14, 12:46 PM, Brian E Carpenter wrote: On 22/10/2014 23:54, Ray Bellis wrote: On 22 Oct 2014, at 02:02, Brian E Carpenter wrote: Up one more level: the charter looks pretty out of date in general. Hi Brian, The charter itself still reflects our primary focus. I believe it still accurately reflects the constraints on our scope. The milestones are admittedly completely out of date! I hope that Mark and I will be able to get some time with our AD in Honolulu to get those updated. Been there, done that, you have my sympathy and understanding ;-). However, I suggest that a security threat analysis would be worth considering as a new charter goal. +1 Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-barth-homenet-hncp-security-trust-01.txt
On 22/10/2014 23:54, Ray Bellis wrote: > On 22 Oct 2014, at 02:02, Brian E Carpenter > wrote: > >> Up one more level: the charter looks pretty out of date in general. > > Hi Brian, > > The charter itself still reflects our primary focus. I believe it still > accurately reflects the constraints on our scope. > > The milestones are admittedly completely out of date! I hope that Mark and I > will be able to get some time with our AD in Honolulu to get those updated. Been there, done that, you have my sympathy and understanding ;-). However, I suggest that a security threat analysis would be worth considering as a new charter goal. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-barth-homenet-hncp-security-trust-01.txt
On 22 Oct 2014, at 02:02, Brian E Carpenter wrote: > Up one more level: the charter looks pretty out of date in general. Hi Brian, The charter itself still reflects our primary focus. I believe it still accurately reflects the constraints on our scope. The milestones are admittedly completely out of date! I hope that Mark and I will be able to get some time with our AD in Honolulu to get those updated. Ray ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-barth-homenet-hncp-security-trust-01.txt
> I agree with whoever it was that said there is not enough explanation > of the threat model in this draft. The result is that I really can't > evaluate whether the proposed solution is complete or adequate. >From my point of view there are two vectors through which you can attack HNCP - as mentioned. First is auto-border-discovery (if you happen to use it) and second is attacking the protocol itself. For #2 the effects of most of the attacks one can probably think of i.e. spoofing, replay, ... as well as simply pretending to be an HNCP/IGP pariticipating router (i.e. speak the protocols regularly) can both lead to various forms of manipulation of the HNCP state. Since the algorithms on top (at least the ones currently defined) are mostly distributed / consensus-based in nature you can pretty much mess with the state without attacking a specific router's HNCP traffic and by just pretending to be a homenet router yourself. Besides most standard end-to-end security solutions cover authentication, encryption, replay protection etc. so should cover most of the attack vectors on the unicast channel which leaves us with the multicast channel which is explained in the draft. TBH replies like "it's not what I expected" or "not enough explanation" doesn't really help if you don't give an explanation or any other form of pointer on how the draft can be improved or what is missing in your mind. As for security of the homenet: The draft briefly mentions securing other protocols like IGPs and the issues with that and proposes that HNCP manages a PSK for them (since thats what IGPs tend to support in terms of authentication). Besides that I don't really want to cover the whole homenet in this draft since this draft should probably be merged with the HNCP main draft at some point. That doesn't me I'm against a separate generic homenet threats draft if anyone volunteers to write one. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-barth-homenet-hncp-security-trust-01.txt
Hi, I agree with whoever it was that said there is not enough explanation of the threat model in this draft. The result is that I really can't evaluate whether the proposed solution is complete or adequate. The other thing that bothers me is that we need a secure homenet, not just a secure HNCP. Protecting HNCP will be pointless if the network is insecure for other reasons. So, what we *really* needs is a full homenet threat analysis. That is not to be found in the architecture RFC-to-be and is not in the WG charter, but I think it should be. Up one more level: the charter looks pretty out of date in general. Regards Brian ___ 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
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
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 & 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
[homenet] HNCP Security & Trust Draft
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
Re: [homenet] HNCP security?
Markus Stenberg writes: > > I have no idea what littleconf-TOFU setup looks like, so cannot > > comment.. > > Guess I’ll come over and discuss this at some point (not sure how > much you have followed the 100+ message thread here). I have skimmed through some of the emails, but not that well, so the security model of the bootstrap process is still unclear for me (I am not sure if it clear for anybody). > > 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. > > Hmmh. In G-IKEv2 case, I am not sure if it is this simple. Because > ultimately you want there to be only one GCKS (per link), but at > boot time, there is lots of raciness about who comes up first, and > decides they are one. > > i.e. > > router 1 boots up > -> anycast > (no reply) > > ~at same time router 2 boots up > -> anycast > (no reply) > > both think they can be the GCKS. I suppose one could define some > robust mechanics to make sure that ultimately you have only one > and/or share state between them so that it does not matter? I think there needs to be some kind of voting process to select the master for each network. This is something that is not really part of the multicast security or security in general, it needs to be defined by the homenet. Also the problem is not just simultaneous boot, but also partitions and reconnects, i.e. when someone unplugs ethernets and partitions the home network in two parts, both of the parts still need to function, i.e. both of parts need to make sure each of them have one master. When user then plugs them back together there is need to select new one. I do not know if that can be combined to the routing information, i.e. routers will know when the links go down and start the process of making sure connected parts of the network is served by master, and starting corrective actions when new links are connected. The corrective operations would most likely be run over unicast, i.e. when new network is connected the two parts have different multicast keys, so those cannot be used, so the master of network 1 could simply connect master of network 2 and they could agree who continues to be master, redistribute new keys, and rekey peers multicast keys so the whole new network has common keys. G-IKEv2 and IKEv2 or whether security protocol is used there, are just tools for such protocol, I do not think that protocol should be part of the the security protocol. -- kivi...@iki.fi ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On 29.9.2014, at 14.57, Tero Kivinen wrote: > Markus Stenberg writes: >> >>> 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.. Guess I’ll come over and discuss this at some point (not sure how much you have followed the 100+ message thread here). >> 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. Hmmh. In G-IKEv2 case, I am not sure if it is this simple. Because ultimately you want there to be only one GCKS (per link), but at boot time, there is lots of raciness about who comes up first, and decides they are one. i.e. router 1 boots up -> anycast (no reply) ~at same time router 2 boots up -> anycast (no reply) both think they can be the GCKS. I suppose one could define some robust mechanics to make sure that ultimately you have only one and/or share state between them so that it does not matter? Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
Ted Lemon 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 , 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 09/29/2014 06:24 AM, Ted Lemon wrote: On Sep 29, 2014, at 9:16 AM, Stephen Farrell 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?
On Sep 29, 2014, at 9:16 AM, Stephen Farrell 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 29/09/14 13:58, Ted Lemon wrote: > On Sep 29, 2014, at 3:50 AM, Stephen Farrell > 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 3:50 AM, Stephen Farrell 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?
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?
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?
On 25.9.2014, at 14.19, Tero Kivinen 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?
Michael Thomas wrote: >> So what about the other way around? To what degrees should my >> homenet trust ISP-maintained CPE? > Sorry, I was talking about the upstream aggregation router, not the > in-home router. That is, if I treat the ISP CPE the same way that I > treat my ISP's aggregation router, I can define it as being > "outside". That, of course, as you note above means that you can't use > their wireless etc lest you open yourself to be p0wned by them. If you are asking if I have to trust the ISP upstream aggregation router (so s/CPE/router/ in >> above), then answer is that router is not involved at all in the homenet's security perimeter. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- pgp1tHk8ZpbvN.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
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. If homenet needs multicast support then it might be good idea to push that document forward. > > 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? NATs should not be problem here in the homenet, I would assume all this runs inside the home, and the boxes in homenet are not going to do nat for ipv6 addresses... > > 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? 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. > 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. If secure multicast is needed, I think going for the g-ikev2 and ESP would most likely be best way. The g-ikev2 specification is as far as I can see ready, so it should be something that can be published quite soon. It will run over separate port from normal IKEv2, so it can be deployed quite easily (meaning it does not mess up existing IPsec in the box), and as msec was not really very widely deployed the changes that the box already has exsiting msec implementation running on that port, is small. > 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. If I remember right g-ikev2 supports multiple group key management protocols and allows download keys from the group controller / key server (GCKS) using IKEv2 to the devices. -- kivi...@iki.fi ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On 9/24/14, 7:46 AM, Michael Richardson wrote: Michael Thomas wrote: >> Michael Thomas 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. Sorry, I was talking about the upstream aggregation router, not the in-home router. That is, if I treat the ISP CPE the same way that I treat my ISP's aggregation router, I can define it as being "outside". That, of course, as you note above means that you can't use their wireless etc lest you open yourself to be p0wned by them. As far as DHCPv6 PD, can you just convince their CPE to bridge and let the aggregation router do it, or perhaps just set up their CPE as a DHCP relay, or maybe something else? As I say I'm not an expert here so sorry if these are dumb questions. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
Michael Thomas wrote: >> Michael Thomas 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 , 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?
On Sep 24, 2014, at 10:00 AM, Steven Barth 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?
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?
Mark Townsley 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 , 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?
On 09/24/2014 05:01 AM, Mark Townsley wrote: 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). No. 1) Unsecured is unacceptable. 2) Pre-shared keys suck, and don't addresses the authz problem. 3) PKI in the traditional sense (eg certs) is an anti-goal. The approach should be a more modern "start by using (naked) public keys as a tool to facilitate the enrollment problem that homenet MUST solve for, and produce solutions that address the security threats, littleconf needs, and low-clue nature of homenets." Mike, uncaffeinated 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 ___ 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?
> On Sep 23, 2014, at 7:22 PM, Michael Richardson wrote: > > > 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. > > 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 , Sandelman Software Works > -= IPv6 IoT consulting =- > > > ___ 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 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 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 8.56, Mikael Abrahamsson wrote: > 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? 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. You cannot really bootstrap them from anything else than that, though, which is a problem.http://tools.ietf.org/wg/msec/ attempted to address this, but I have not really seen it in the wild as open source (for example, no support in StrongSwan[1]). (Cisco did GDOI in e.g. DMVPN at least.) -Markus P.S. I’d like to be proven wrong on this front - ‘just use IKE+IPsec’ is a good story, but without equivalently good (in terms of what is used for auth*, and how secure it is) support for both unicast and multicast, I do not really think it applies as-is to anything that makes decisions that matter also based on multicast packets. [1] https://wiki.strongswan.org/projects/strongswan/wiki/IpsecStandards ___ 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?
On Sep 23, 2014, at 7:57 PM, Douglas Otis 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 Sep 23, 2014, at 3:39 PM, Michael Thomas wrote: > > On 9/23/14, 1:07 PM, Michael Richardson wrote: >> Michael Thomas 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 9/23/14, 1:07 PM, Michael Richardson wrote: Michael Thomas 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? Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
Michael Thomas 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 , 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?
STARK, BARBARA H wrote: > If the concern is with a man-in-the-middle attack on HNCP messages, > then point-to-point security, using encryption with any key that the 2 The concern is man-in-the-middle "attacks" on HNCP messages by an outsider, not another member of the household. Or, more specifically, the outsider being a misconfigured (physical) neighbour. Possession of the WPA2 passphrase means that the router is part of my home. > If the goal is to know whether an endpoint is authorized to > send/receive a HNCP message WPA2-PSK is also useless. It authorizes no > such thing. Users should be free to run HNCP in a manner that requires > no explicit authorization. If explicit authorization to run HNCP is > desired by the user, then such authorization must come from a person > with physical access to the home network and its devices, and such > authorization must be specific to the running of HNCP and/or a role in > home network configuration. What do you mean by "user" here. Last I checked, my wife is a user, and I'm sure that neither her person, nor her mobile phone, nor her chrome book need to run HNCP. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- pgp6xKto475UX.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?
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 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 , 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?
> >> 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. Possession of the WPA2 passphrases authorizes access to that particular Wi-Fi network -- nothing more and nothing less. And they authenticate nothing (because they are shared). If the concern is with a man-in-the-middle attack on HNCP messages, then point-to-point security, using encryption with any key that the 2 endpoints can agree on (such as simple TLS with HTTP digest authentication) makes sense. This is just about making sure the endpoints remain the same over the course of messaging and that nothing inserts itself into the conversation (or overhears the conversation). If the desire is to ensure endpoints can be identified over the course of many conversations, then consistently-used self-generated keys are sufficient. Because WPA2 passphrases are shared, they are useless here. If the goal is to know whether an endpoint is authorized to send/receive a HNCP message WPA2-PSK is also useless. It authorizes no such thing. Users should be free to run HNCP in a manner that requires no explicit authorization. If explicit authorization to run HNCP is desired by the user, then such authorization must come from a person with physical access to the home network and its devices, and such authorization must be specific to the running of HNCP and/or a role in home network configuration. But to be honest, I have no clue what the potential HNCP attacks and vulnerabilities (and security goals) are. What does HNCP security need to protect against? I agree that documentation of overall homenet threats and vulnerabilities isn't what's needed to understand specific HNCP threats and vulnerabilities. But is there a plan to document these for HNCP? Barbara ___ 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 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?
Steven Barth 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 , 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?
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. 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 Richardson , Sandelman Software Works -= IPv6 IoT consulting =- pgpgaOXNHBHEk.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
Markus Stenberg 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, particula
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" wrote: > >On Sep 20, 2014, at 12:57 AM, Steven Barth 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 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?
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 19 Sep 2014, at 21:59, Ted Lemon wrote: > >> On Sep 19, 2014, at 4:54 PM, Michael Thomas 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?
On Sep 19, 2014, at 4:54 PM, Michael Thomas 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 9/19/14, 3:28 AM, Ted Lemon wrote: On Sep 18, 2014, at 6:04 PM, Mark Baugher wrote: 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. This discussion to some extent made it into the homenet architecture document, but I don't think the whole discussion was captured in any document, and that's why we're having the discussion again. 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. If we did, my preference would that it not be HNCP specific. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On 20/09/2014 08:05, Michael Thomas wrote: > > On 9/19/14, 12:38 PM, Ted Lemon wrote: >> On Sep 19, 2014, at 1:22 PM, Mark Baugher 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. I agree. I think there are a number of steps to consider, and how to secure an individual point-to-point communication is late in the list. Even without a threat analysis, I can see: 1. Establish the boundary (and Tim's recent power-line story underlines that this isn't trivial). 2. Establish the trust anchor (you're bound to need one). 3. Establish (trusted identity + public key) for every device. 4. Authorise each device for selected roles. 5. Distribute public keys accordingly. Do that, and it becomes a relatively minor point which crypto protocol you choose. Brian ___ 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 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 1:22 PM, Mark Baugher 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 Sep 19, 2014, at 9:37 AM, Ted Lemon wrote: > On Sep 19, 2014, at 11:59 AM, Mark Baugher wrote: >> How could it happen? > > Isn't that what we've been discussing? 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? 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?
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 Date: Thursday, September 18, 2014 at 3:06 PM To: David R Oran , Rene Struik Cc: , Markus Stenberg 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 > <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 7:17 AM, Steven Barth 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?
On Sep 19, 2014, at 11:59 AM, Mark Baugher 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 8:54 AM, Ted Lemon wrote: > On Sep 19, 2014, at 10:52 AM, Steven Barth 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 10:52 AM, Steven Barth 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 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?
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. 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. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On 09/19/2014 07:17 AM, Steven Barth 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. Let's be clear: the enrollment and authorization problems are The hard problems. How the bits one the wire are encrypted/authenticated is straightforward in comparison. Not having a standardized way of setting this up will lead to chaos and the high likelihood that homenet devices will not interoperate. Doubly so because the homenet architecture requires as little operator intervention as possible. 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. 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 02:06 AM, Markus Stenberg wrote: On 19.9.2014, at 11.18, 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. So DTLS it is? Because I do not want to reinvent any crypto wheels I do not have to. Without a list of threats, it's impossible to know if "DTLS is it". 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. The thing that I'm curious about is whether we can use HNCP itself as a way to distribute authz for itself, and potentially for other homenet related protocols, cf Brian's MUST a few messages ago. Mike ___ 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?
On Sep 19, 2014, at 3:25 AM, Ted Lemon wrote: > On Sep 18, 2014, at 6:46 PM, Mark Baugher 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 Sep 18, 2014, at 6:04 PM, Mark Baugher wrote: > 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. This discussion to some extent made it into the homenet architecture document, but I don't think the whole discussion was captured in any document, and that's why we're having the discussion again. I agree that we discussed this before, but we are getting a little bit more into the details now, so I don't think that's a bad thing. This discussion doesn't seem to have degenerated into a bunch of people talking past each other, so let's be thankful for small favors. :) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Sep 18, 2014, at 6:46 PM, Mark Baugher 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. 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. ___ 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 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 18, 2014, at 12:34 PM, Ted Lemon wrote: > On Sep 18, 2014, at 4:27 AM, STARK, BARBARA H 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?
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" Date:09/18/2014 5:02 PM (GMT-06:00) To: Randy Turner , Michael Thomas , 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 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 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?
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 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 > Date:09/18/2014 5:12 PM (GMT-06:00) > To: Randy Turner > Cc: "homenet@ietf.org Group" > Subject: Re: [homenet] HNCP security? > > > On Sep 18, 2014, at 2:37 PM, Randy Turner 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 > > 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?
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 Date:09/18/2014 5:12 PM (GMT-06:00) To: Randy Turner Cc: "homenet@ietf.org Group" Subject: Re: [homenet] HNCP security? On Sep 18, 2014, at 2:37 PM, Randy Turner 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 > 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?
On Sep 18, 2014, at 2:37 PM, Randy Turner 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 > 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?
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 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 8:57 AM, David R Oran wrote: > > On Sep 18, 2014, at 11:46 AM, Rene Struik 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?
> 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 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?
How do you bootstrap trust relationships without an initial certificate (whether installed at manufacturing or during a customer fulfillment stage) ? Original message From: Michael Thomas 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 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?
> 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, 8:57 AM, David R Oran wrote: On Sep 18, 2014, at 11:46 AM, Rene Struik 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?
On 09/18/2014 08:57 AM, David R Oran wrote: On Sep 18, 2014, at 11:46 AM, Rene Struik 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. Raw keys in and of themselves provide provable identifiers of the public key: the fingerprint itself. It remains to be seen whether some other identity needs to be bound to it, and, of course, certs are hardly the only way to do that. 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. Mike ___ 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 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?
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 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?
On 09/18/2014 08:24 AM, Markus Stenberg wrote: With device certificates, you still have the original authz problem. That is, just because I can identify you reliably tells me nothing about whether I want to participate with routing updates with you. So in that way, they not any more useful than naked keys. If the device certificate is on hardware, you cannot generate them at will, and therefore they _are_ more useful as you can e.g. blacklist device and be sure that even with leap of faith code active, it will not come out of woodwork with new certificate. Revocations again gets back to the threat model: what attacks are we trying to prevent (or not). Without knowing that, it's hard to say whether device certs help any, especially considering that there are perfectly acceptable homenet routers that will never be born with a device cert. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
Whether or not you do leap of faith, certificates _do_ provide extra value. - you can produce them/validate via (local / cloudy) CA (which may also imply authorization in addition to authentication, or not) - you can have them from hardware (which makes producing spurious ones much harder, assuming the hardware certificates in and of themselves are authenticable) 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). That said, I think there is probably room for both PSK-based and some PKI-based solution here, but I do not believe that much in raw public keys any more. Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On 18.9.2014, at 18.17, Michael Thomas wrote: > On 09/18/2014 06:49 AM, Markus Stenberg wrote: >> On 18.9.2014, at 16.05, Ted Lemon wrote: >>> On Sep 18, 2014, at 7:38 AM, STARK, BARBARA H 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). > With device certificates, you still have the original authz problem. That is, > just because I can identify you > reliably tells me nothing about whether I want to participate with routing > updates with you. So in that > way, they not any more useful than naked keys. If the device certificate is on hardware, you cannot generate them at will, and therefore they _are_ more useful as you can e.g. blacklist device and be sure that even with leap of faith code active, it will not come out of woodwork with new certificate. (See above.) Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On 09/18/2014 06:49 AM, Markus Stenberg wrote: On 18.9.2014, at 16.05, Ted Lemon wrote: On Sep 18, 2014, at 7:38 AM, STARK, BARBARA H 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). With device certificates, you still have the original authz problem. That is, just because I can identify you reliably tells me nothing about whether I want to participate with routing updates with you. So in that way, they not any more useful than naked keys. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
One advantage of using X.509 certs is that the code to support them is widely available with multiple implementations. I guess then you could go all the way and use the whole DTLS for HNCP unicast traffic (and keep MC unencrypted since its more or less a signaling channel for UC and doesn't contain sensitive data). This would then avoid the need to redefine and reimplement most of the DTLS features in HNCP anyway. Cheers, Steven Another is that the same cert can be used for TLS negotiation in embedded web services, etc. to each device. And of course if the registration mechanism is integrated into client OS's then those X.509 certs can easily participate in the usual trust policy stuff supported by those OS's. On Sep 18, 2014, at 6:34 AM, Ted Lemon wrote: On Sep 18, 2014, at 4:27 AM, STARK, BARBARA H 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. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet _ Michael Sweet, Senior Printing System Engineer, PWG Chair ___ 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 18.9.2014, at 16.05, Ted Lemon wrote: > On Sep 18, 2014, at 7:38 AM, STARK, BARBARA H 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 Sep 18, 2014, at 7:38 AM, STARK, BARBARA H 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 09/18/2014 04:50 AM, Michael Sweet wrote: One advantage of using X.509 certs is that the code to support them is widely available with multiple implementations. Another is that the same cert can be used for TLS negotiation in embedded web services, etc. to each device. And of course if the registration mechanism is integrated into client OS's then those X.509 certs can easily participate in the usual trust policy stuff supported by those OS's. IMHO, if you're not going to use a CA, then putting x509 bits around the public key only serves to confuse the issue in my experience, and makes for a much more complicated solution. Using raw public keys is really quite simple codewise. And, of course, nothing prevents you from manufacturing those fake x509 certs for protocols that require them, and just using the bare key for those that don't. That said, it is possible to envision using local CA functionality such that any currently enrolled homenet router is able to sign a new enrollee's key which allows it to present that cert to any other homenet device without prior knowledge of that key and be accepted. It's just another way of distributing the database. Not sure how any of this would work with revocations though. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
