Subject: [Secdispatch] Appropriate WG for secure communication between networks and unknown clients

From: Tommy Jensen <[email-masked]>
Date: Mon, 3 Aug 2020 17:58:51 +0000

Hey SECDISPATCH,

In the ADD WG, there's been a lot of discussion on the topic of secure communication between networks and clients that aren't preconfigured. The context is how a network can convince a client, which has no out-of-channel configuration to use for confirming network identity, that it has recommendations that can be distinguished from an attacker on the network.

This was brought up in our WG as part of the "Network A recommends DNS server B" which is done over DHCP or RAs today. With encrypted DNS protocols now available, we want to allow a network to advertise its own encrypted DNS servers. However, if we use DHCP or RAs as they are defined today, this can be hijacked by an attacker to convince clients to setup secure connection to an attacker's server.

We know secured network configuration without out-of-band configuration is a hard problem but want to discuss it in a larger context than just DNS so we don't try to define a mechanism that cannot be reused by other scenarios. This mailing list was recommended in our IETF 108 WG session as a good contact for helping us find the right audience for this discussion. Any thoughts?

Thanks,
Tommy Jensen

---

From: Richard Barnes <[email-masked]>
Date: Mon, 3 Aug 2020 15:36:25 -0400

Hey Tommy,

Good question.  It seems like there's a threshold question here of how the
endpoint gets configured so that it can authenticate the network.  In that
regard, I don't think you're going to be able to avoid *some* out of band
configuration.  The silver lining seems to be, though, that there are lots
of existing OOB-configured things available that one could imagine relying
on -- from full 802.1X to simple WEP passwords.  Also, if we can get a
robust mechanism here, it would be useful for multiple things (just like
DHCP is); for example, you could distribute captive portal / network access
information that way.

All of which sounds like a big enough piece of work to merit its own
working group.  Between the multiplicity of bootstrapping approachs you'll
want to cover and the generality of the solution.  Honestly, it might not
even belong in the SEC area, since a lot of the considerations are more
INT-like -- one way to read this is as S-DHCP.

But this is a problem I would like to see solved.

--Richard

On Mon, Aug 3, 2020 at 1:59 PM Tommy Jensen <Jensen.Thomas=
[email-masked]> wrote:

> Hey SECDISPATCH,
>
> In the ADD WG, there's been a lot of discussion on the topic of secure
> communication between networks and clients that aren't preconfigured. The
> context is how a network can convince a client, which has no out-of-channel
> configuration to use for confirming network identity, that it has
> recommendations that can be distinguished from an attacker on the network.
>
> This was brought up in our WG as part of the "Network A recommends DNS
> server B" which is done over DHCP or RAs today. With encrypted DNS
> protocols now available, we want to allow a network to advertise its own
> encrypted DNS servers. However, if we use DHCP or RAs as they are defined
> today, this can be hijacked by an attacker to convince clients to setup
> secure connection to an attacker's server.
>
> We know secured network configuration without out-of-band configuration is
> a hard problem but want to discuss it in a larger context than just DNS so
> we don't try to define a mechanism that cannot be reused by other
> scenarios.. This mailing list was recommended in our IETF 108 WG session as
> a good contact for helping us find the right audience for this discussion.
> Any thoughts?
>
> Thanks,
> Tommy Jensen
> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>

---

From: Mohit Sethi M <[email-masked]>
Date: Tue, 4 Aug 2020 09:14:22 +0000

Hi Tommy,

Would it be fair to summarize your requirements as:

- Client devices don't have any pre-configured credentials or information about the network

- No out-of-band configuration of any sort is possible

In that case, I guess I don't have any black magic to offer. The only techniques that I am aware of are in research literature: see secure in-band pairing: https://www.usenix.org/legacy/events/sec11/tech/full_papers/Gollakota.pdf

--Mohit

On 8/3/20 8:58 PM, Tommy Jensen wrote:
Hey SECDISPATCH,

We know secured network configuration without out-of-band configuration is a hard problem but want to discuss it in a larger context than just DNS so we don't try to define a mechanism that cannot be reused by other scenarios.. This mailing list was recommended in our IETF 108 WG session as a good contact for helping us find the right audience for this discussion. Any thoughts?

Thanks,
Tommy Jensen

_______________________________________________
Secdispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/secdispatch

---

From: Mohit Sethi M <[email-masked]>
Date: Tue, 4 Aug 2020 09:14:57 +0000

Hi,

I agree that it would be nice to solve this problem. However, I would like us to resist the temptation of designing yet-another-protocol.

As Richard mentioned, IEEE 802.1X is a great tool box which can provide:
- per-device individual credentials (vs. network-wide secrets)
- over 52 EAP authentication methods to choose from
- revocation of access of individual devices is straightforward
- possibility of device isolation into separate VLANs.

The popular 4 (windows, iOS, android, and linux) support it natively. It is widely deployed in enterprise networks.

Why not reuse it in the networks that you have in mind? And as someone said on the ADD mailing list, home is the new office and home networks are the new enterprise networks. Admittedly, there are some stumbling blocks that make the deployment of 802.1x challenging for ordinary users. It would be great if we could solve that.

--Mohit

On 8/3/20 10:36 PM, Richard Barnes wrote:
Hey Tommy,

Good question.  It seems like there's a threshold question here of how the endpoint gets configured so that it can authenticate the network.  In that regard, I don't think you're going to be able to avoid *some* out of band configuration.  The silver lining seems to be, though, that there are lots of existing OOB-configured things available that one could imagine relying on -- from full 802.1X to simple WEP passwords.  Also, if we can get a robust mechanism here, it would be useful for multiple things (just like DHCP is); for example, you could distribute captive portal / network access information that way.

All of which sounds like a big enough piece of work to merit its own working group.  Between the multiplicity of bootstrapping approachs you'll want to cover and the generality of the solution.  Honestly, it might not even belong in the SEC area, since a lot of the considerations are more INT-like -- one way to read this is as S-DHCP.

--Richard

On Mon, Aug 3, 2020 at 1:59 PM Tommy Jensen <Jensen.Thomas=[email-masked]<mailto:[email-masked]>> wrote:
Hey SECDISPATCH,

Thanks,
Tommy Jensen

---

From: Töma Gavrichenkov <[email-masked]>
Date: Tue, 4 Aug 2020 12:20:10 +0300

Peace,

On Mon, Aug 3, 2020, 8:59 PM Tommy Jensen <Jensen.Thomas=
[email-masked]> wrote:

> communication between networks and clients that aren't preconfigured.
>

While this is an interesting area to develop, it seems like current efforts
belong more to IRTF than IETF, don't they?

--
Töma