Subject: [Captive-portals] A final check on draft-ietf-capport-architecture-09

From: "Martin Thomson" <[email-masked]>
Date: Mon, 10 Aug 2020 10:10:47 +1000

The editors of draft-ietf-capport-architecture have put in a huge amount of work over the past few weeks in addressing the review comments.

https://tools.ietf.org/html/draft-ietf-capport-architecture-09

As there have been quite a few changes, I would like to request that people take a brief look again before we proceed.  I've been watching closely, and the changes look good, but I would like to confirm.  The changes are:

https://tools.ietf.org/rfcdiff?url2=draft-ietf-capport-architecture-09.txt

Please send comments before 2020-08-16.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Aug 2020 00:18:49 -0400

I've read through the diffs:

One that jumped out at me:
   If the API server is identified by
   IP address, the iPAddress subjectAltName is used to validate the
   behavior described above.

This was added based upon some review comment.
While I can't really object to the idea, I am concerned.
What are the transports that result in only being able to provide a public IP
address? How many common PKI trust anchors are supporting iPAddress SANs today?

This seems like it's opening a situation where someone will deploy on RFC1918
addresses and then expect clients to do some exception processing.
Particularly in corporate guest networks where they only tested with their
devices that already have their private PKI anchors.  I can think of a few
captive portal product managers that I have interacted with that would simply
not understand this.
I'd rather we didn't allow for iPAddress SANs, but it's not a sword I'll die on.

The next part says:
  An Enforcement Device SHOULD allow access to any
  services that User Equipment could need to contact to perform
  certificate validation, such as OCSP responders, CRLs, and NTP
  servers;

That's a good list, and that list can be seen from looking at the
certificates that the captive portal operator is going to use.
But, aren't there *also* systems (Mozilla? Chrome?) where the respective
vendors are collecting that info into a central place to make stuff go
faster?   I can't quite find what I'm looking for in a search, because
OCSP-Stapling is not what I'm talking about, and eliminates the need.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 10 Aug 2020 15:00:56 +1000

> I've read through the diffs:

Thanks!

> address? How many common PKI trust anchors are supporting iPAddress SANs today?

There are no methods for providing an API URL that don't support a domain name.  That said, this iPAddress thing is just reiterating a requirement from RFC 6125.  It isn't *widely* supported, but most clients do respect iPAddress SANs (browsers do for certain), and there are a couple of CAs that support issuance.  ACME recently grew a validation mechanism for IP (RFC 8738).

> I'd rather we didn't allow for iPAddress SANs, but it's not a sword I'll die on.

Ack.  Personally, I'm more concerned about implementations allowing an override option other than through modifying the trust store.  A domain name is equally problematic there (let's hope we don't see .home addresses...).  But I don't see any easy path to a per-host override based on what I've seen in implementations so far.

> OCSP-Stapling is not what I'm talking about, and eliminates the need.

Yes, browsers are providing systems that help with revocation.  Mozilla has OneCRL and CRLite; Chrome has CRLSets; offhand, I don't know what Microsoft and Apple might be doing differently.  Those systems that I'm aware of don't require network access at validation time.  The whole point being to provide timely information about revocation without depending on a live OCSP or CRL fetch (which have poor privacy properties in addition to adding to fragility).

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Aug 2020 12:31:57 -0400

> Ack.  Personally, I'm more concerned about implementations allowing an
    > override option other than through modifying the trust store.  A domain
    > name is equally problematic there (let's hope we don't see .home
    > addresses...).  But I don't see any easy path to a per-host override
    > based on what I've seen in implementations so far.

Again, some enterprise PHB will point to this paragraph and tell the techie
that s/he doesn't need to do things the right way.  I've been there.
So I would like to know why we added it.  We can specify a subset of RFC6125.

    > Yes, browsers are providing systems that help with revocation.  Mozilla
    > has OneCRL and CRLite; Chrome has CRLSets; offhand, I don't know what
    > Microsoft and Apple might be doing differently.  Those systems that I'm
    > aware of don't require network access at validation time.  The whole
    > point being to provide timely information about revocation without
    > depending on a live OCSP or CRL fetch (which have poor privacy
    > properties in addition to adding to fragility).

Ah, okay.  The CRL is "built-in", so it does not need to be fetched while in
captivity. Thank you.

---

From: Erik Kline <[email-masked]>
Date: Mon, 31 Aug 2020 22:28:39 -0700

One thing I realized that we didn't discuss in 7710bis, and didn't really
discuss here either, is the issue of devices attached to routers which are
themselves on the link with the provisioning service.

Such clients would not have a way to receive an RA option nor any of the
DHCP options since we didn't say what routers that observe these on a
network should do (e.g. routers should/may include verbatim the 7710bis
options in any of the applicable mechanisms for downstream clients).

The section 2.5 captive portal signal might be able to come to the rescue
here, but as we don't have such a thing.

But...maybe that's a separate document?

On Sun, Aug 9, 2020 at 5:11 PM Martin Thomson <[email-masked]> wrote:

> The editors of draft-ietf-capport-architecture have put in a huge amount
> of work over the past few weeks in addressing the review comments.
>
> As there have been quite a few changes, I would like to request that
> people take a brief look again before we proceed.  I've been watching
> closely, and the changes look good, but I would like to confirm.  The
> changes are:
>
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 01 Sep 2020 15:42:31 +1000

These cases, along with the very common case of a router that is on-premises and sits between an ISP and a local network, were discussed, but I don't recall ever reaching a conclusion.

On Tue, Sep 1, 2020, at 15:28, Erik Kline wrote:
> One thing I realized that we didn't discuss in 7710bis, and didn't 
> really discuss here either, is the issue of devices attached to routers 
> which are themselves on the link with the provisioning service.
> 
> Such clients would not have a way to receive an RA option nor any of 
> the DHCP options since we didn't say what routers that observe these on 
> a network should do (e.g. routers should/may include verbatim the 
> 7710bis options in any of the applicable mechanisms for downstream 
> clients).
> 
> The section 2.5 captive portal signal might be able to come to the 
> rescue here, but as we don't have such a thing.
>

---

From: Erik Kline <[email-masked]>
Date: Mon, 31 Aug 2020 23:17:10 -0700

Warren and I had discussed whether {it would suffice for there to be /
there needs to be} an ops draft somewhere that says "if you see these
things upstream, replicate them downstream (unless you somehow know
better)".

DNS and NTP servers might be in this set.  7710bis would definitely be in
this set.

On Mon, Aug 31, 2020 at 10:43 PM Martin Thomson <[email-masked]> wrote:

> These cases, along with the very common case of a router that is
> on-premises and sits between an ISP and a local network, were discussed,
> but I don't recall ever reaching a conclusion.
>
> > > The editors of draft-ietf-capport-architecture have put in a huge
> amount of work over the past few weeks in addressing the review comments.
> > >