Markus Stenberg <markus.stenb...@iki.fi> wrote:
markus> 1) Can we assume secure L2 and/or appropriate device
markus> configuration by the manufacturer/ISP(/user)? (This is what I can
markus> assume in my own home.)
>> I think that we can assume that wired links are secure.
>> The only time we care if wireless is secured is when we want to form an
>> adjacency over the wireless link. I think it is acceptable to refuse
>> to form an adjancency over an insecured wireless link.
> This can also be automated (for first-hop wireless). However, in the
> ‘what-if’ land, wired -> wireless bridges, and wireless -> wireless
> extenders that do things insecurely cannot be detected.
Yes, I agree.
Let me restate that I think we can "securely" to do TOFU across the wired
link. If that link turns into something less secure, then that's okay.
>> I think it is acceptable to do some kind of TOFU (using IPsec with IKEv2
>> even) point to point across wired links, and having done that, if there
>> is an adjancy later possible between those two devices over what would
>> otherwise be an insecure link, that the previously exchanged keys work.
>> That means one can plug two routers together with a cable, and then
>> separate them, knowning that the two routers will remain "entangled"
>> (I’m making allusions to
http://en.m.wikipedia.org/wiki/Quantum_entanglement)
> I assume you mean:
> - On wired links: opportunistic IKEv2 attempt, fallback to non-IPsec
> (if no IPsec available? if no key?), and update the SPD dynamically
> based on successful IKEv2 attempts.
> - On the wireless (all? only insecure?): force IPsec using the known
> good SPD entries.
> That is interesting scheme. Implementation-wise, it sounds somewhat
painful though.
yes, I agree that it's probably difficult with the available implementation of
openwrt
IKEv2 daemons... I don't think it's architecturally that hard.
>> I further suggest that if two routers have wireless that they might well
>> have a WPA2/PSK available to them, and that they can and SHOULD use
something
>> derived from that key to authenticate each other. Could be over IKEv2,
yes.
> I _think_ we have to assume some passwords somewhere.
> - WPA2 PSK on almost all home routers by default (most home network
> access these days is wireless)
yes, agree. And if they have multiple routers, they likely have the same
WPA2-PSK.
> - admin password (for those user actually has access to, and are not
> part of some super-fancy PKI scheme for authenticating administrator)
I'm less thrilled about using the admin password. They have less likely hood
of being changed, and ideally, they are encrypted/hashed in a way that the
raw password can't be seen.
markus> 2) If not, should the solution be some sort of pre-shared key
markus> scheme? (If not, please explain your alternative solution.)
>>
>> If we assume the abovekey, we could use it to derive a pre-shared key
for a
>> multicast IPsec SA using AH. Can we assume, declare, that if you don't
know
>> the key, that you skip the AH header, and process the HNCP that is
inside as
>> if it wasn't secured at all? We wanted to do that for SEND, but there
were
>> IPsec implementations that could do that, because we overspecified AH
back in
>> 2401. Given that home routers are purpose built boxes, and not generic
>> random hosts, perhaps we can specify this behaviour.
> Hmm. I wonder if that assumption would work bidirectionally,
> though. That is, the not-key-knowing router sending plaintext traffic,
> and the others using the information? If so, what is the value of
> having the (optional) authentication at all?
> If assumption is not bidirectional, then the distributed algorithms
> would not work very well over such protocol - unless the
> unauthenticated messages were just used for bootstrapping the trust
> somehow, but it is not clear to me how that would happen either. Of
> course, they could be used to show user some error (if the router
> actually had UI of some kind) but not much else that I can see.
That's what I would suggest: unauthenticated messages are to bootstrap trust.
Possibly that involves an item on a web page saying, "Router XYZ wants to
join Stenberg House, permit Y/N", perhaps can flash "attention" LED on front.
That would only be used if the network had been set to paranoid secure,
and/or if the wired-TOFU didn't work.
markus> 2.1) And if so, should it be manually keyed IPsec (multicast
markus> prevents e.g. IKE)? (This is what is in the draft currently.)
>> Yes, if we can make this AH assumption of skipping, so that we can get
TOFU
>> to work.
> If we assume some psk on all routers, we can probably bootstrap
> ’something’ without TOFU too?
I agree; but I think that TOFU would be useful here, particularly if the
router isn't wireless capable. Maybe it is a bridge to the LLN, etc.
Maybe that router has wireless, but it's a different wireless and does not
share the same ESSID (cf: Fred's house requirements from IETF76 or something)
> Speaking of IPsec in general, I had a chat with Steven about this, and
> the conclusion was more or less this:
> - (HNCP) unicast works with (opportunistic) IKEv2 or manual key fine
Agreed.
> - (HNCP) multicast works with manual key, but currently is not used for
> anything sensitive (just change detection mechanism, actual state
> changes done via unicast due to multicast size limit)
Agreed.
> => From my point of view, plaintext multicast + unicast IKEv2 with
> (opportunistic) authentication would be perfectly fine too. And as long
> as confidentiality is not desired for the traffic, security properties
> would be actually better than for manually keyed IPsec.
Also agreed.
> If confidentiality is desired, equation changes; however, even when
> using manually keyed IPsec, the fact that there _are_ changes in
> network topology cannot be hidden, from traffic analysis, so I am not
> sure if it is significantly different outcome from the
> confidentiality-only-on-unicast.
Given that we are talking about routers/switches that probably have direct
ethernet to wired computers, (and the router controls the promisc of the
switch) and have WEP/WPA on wireless links, I would suggest further
confidentiality against end-hosts is redundant.
>> I realize that there is an issue with cable modems and FTTH systems such
that
>> the ISP boundary can be hard to recognize. I propose that HNCP use
scope-5
>> multicast, and that we try to convince the Broadband forum that it's
cable
>> modems should drop scope-5 multicast, if they see it. Further, we have
the
>> heuristic that if we saw DHCPv6PD on that interface, it might be an ISP.
>> (If we also saw DHCPv6PD, and we saw authenticated HNCP, then it is
internal)
> I think use of link-local multicast is perfectly fine. Their cable
> modems SHOULD/MUST configure the cable interface as external in any
> case, which has both firewalling implications as well as no HNCP or
> routing protocol traffic on the interface.
yes.
> Fully bridging cable modems are different beast, but even in their
> case, if the border detection works fine (=there is PD prefix or IPv4
> DHCP available there), the HNCP implementations should treat the
> interface as external based on autodetection in any case.
Also agreed.
I have some concerns with that some PPPoE/DSL deployments might leak unicast
ethernet packets between houses, but no evidence that this is the case. That
interface would be dubious to be an internal interface as it has the PPPoE on
it, and this is perhaps a case where an override would be desired if the home
owner really needs that ethernet port.
> So far identified security options:
> 1. no crypto, but fixed interface categories (no HNCP on untrusted L2
links)
> 2. manually keyed IPsec (using PSK, provisioned in advance)
> 3. {manual keys, certs, something else} IKEv2 on unicast, ignore
> multicast (and write in draft no state exchange based on multicast,
> just change notification)
> 4. opportunistic variant of the above, with e.g. self-signed certs, and
> leap of faith happening on interface type
> 5. web of trust in HNCP (Xavier’s draft). The current form of _that_
> draft, for the record, is not really final from my point of view but
> I’m talking more about the general idea.
> [4] scheme in and of itself would have no way of transmitting ’these
> are self-signed certs I trust’ to other nodes it does trust. Therefore,
> if we want to do things in opportunistic way, [5] > [4] in terms of
> user experience, as it would share the trust state across the whole
> home network _using already trusted node set_, and therefore the number
> of ‘pairings’ in the opportunistic scheme would be less. Of course, web
> of trust could be also be based on CA hierarchy or whatever, so it is
> definitely the flexible choice. However, it does imply quite a bit of
> changes to HNCP draft too (or extra draft as it is currently).
> That said, I personally like [1]-[3], and [4]/[5] seem complex.
I think that the words "manual keys" is confusing.
In [2] you mean an IPsec Multicast key Keyed using a Key Derived from the
WPA2-PSK.
Perhaps we need to make up a TLA for that.... IMKDW. (If you know the
Sandler film "Jack/Jill", that reminders of of "I'm Kidding/I'm Kidding", but
I'm not)
In [3] one uses the same WPA2-PSK to derive a key to authenticate the IKEv2
session (I mean using the "Shared Key Message Integrity Code"). Perhaps we
want to use that to bootstrap to a self-signed or raw public. There are
advantages to leaving the WPA2-PSK behind, and there is also the TOFU and
pre-configured cases such that it would make more sense to normalize things.
(Now, I'll go read the other 39 messages in this thread)
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
pgpcnjWOefom0.pgp
Description: PGP signature
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
