Re: [homenet] Securing HNCP - comments?

[Dave Taht <[e-mail]>]

I have been watching this draft evolve now for a while, on
authenticated routing exchanges. Perhaps it would provide some insight
on 3 and 4 below.

http://tools.ietf.org/html/draft-ovsienko-babel-hmac-authentication-09

running code (in quagga, only, at present).

On Thu, Jun 26, 2014 at 11:34 PM, Markus Stenberg
<[e-mail]> wrote:
> (This could have been a draft too, but I’m starting my vacation soon and I don’t want to post any more of those. Sorry.-Markus)
>
> Current HNCP draft specifies security very vaguely, as it was originally based on just some napkin thoughts last year on ‘it would be nice to have authenticated TLVs’.
>
> However, what are we protecting against, how, and should we go through the trouble at all? For all of these attacks, we have to assume _some_ network level access to a home network.
>
> Let us consider potential attacks and their applicability on a home network:
>
> [1] Pretend to be a client: no, we cannot protect against this, all clients are not currently authenticated and not in foreseeable future either. 802.1x not to even mention MACSec support on wired ports is mostly nonexistent in home routers.
>
> [2] Replace upstream router on the upstream link. We cannot do anything about this, and as your packets already go to e.g. NSA, assumption of privacy is moot so this battle is lost. This attack may be harder to mount due to upstream link being typically wired, hard to reach, etc.

To me an authenticated exchange could add meat to the "I'm home", or
"at work" concepts much like how windows works today. Homeplug
devices, for example, have the concept of "pairing", as does
bluetooth, and a few other technologies.

We're still screwed on rogue routers by things like mac spoofing, but
at a higher level you could periodically be doing a challenge/response
to the gateway router to ensure you are talking to the right thing, or
(as per the above link) prefer authenticated routes.

> [3] Pretend to be upstream router on some other link. We can protect against this with fixed categories of interfaces, but securing HNCP has nothing to do with it as upstream router doesn’t talk HNCP.
>
> [4] Pretend to be an inner router.
>
> What are their implications?
>
> [1]: Any resource in-home _can_ be accessed and there is not much that can be done given access to a non-guest link.

What often happens today is a mac filter list, which is somewhat effective.

> [2,3]: Any traffic on the Internet is public (and what else is new?).

How does this bear on hncp?

>
> [4]: If impersonation is possible, man-in-the-middle and potentially denial of service attacks on home network become possible.

impersonation in a routed environment has some interesting subtleties to it.
Take a world where you have a rogue device participate in the local
routing protocol and announce that it's on 75.75.75.75 (comcast's
dns), or 8.8.8.8, but is really acting as a dns server and sending
upstream requests to a rogue dns server (a-la dnschanger)

(this is partially why I made a big push to put bcp38 on, on, in
cerowrt, by default)

>
> How could [4] be prevented then? In ascending order of complexity..
>
> [S4-1] Manual configuration of categories overriding automated border discovery. Defining either in the actual router product, or via configuration which interfaces to talk HNCP (and RP) on, where potential upstream links may never be, can be or always are.
>
> [S4-2] Punt on security in HNCP, and just use e.g. IPsec with manual keying as currently specified in the draft. Setting up the shared PSK for the set of routers is left to the as manual configuration exercise for the owner of the devices.
>
> [S4-3] HNCP-level PSK shared among all routers. Same bootstrap issues as [S4-2], may be able to get rid of manually keyed IPsec dependency.
>
> [S4-4] Some public key cryptography solution operating with just raw keys (there is a draft in the works on how to do this in HNCP)
>
> [S4-5] Some public key cryptography solution with CA hierarchy (similar to behringer-bootstrap)
>
> The big question is, are the S4-3+ really worth it? And what is the sane way to do it if they are? Can we actually become RFC with just S4-1 and S4-2? In case we go for public key-cryptography: what do we do about routing protocols mostly relying on shared secrets for authentication?
>
> - Markus and Steven
>
> _______________________________________________
> homenet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/homenet



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article