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

[Michael Richardson <[e-mail]>]

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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-