Re: [Captive-portals] A final check on draft-ietf-capport-architecture-09
On Mon, Aug 10, 2020, at 14:18, Michael Richardson wrote: > I've read through the diffs: Thanks! > 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? 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. > 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. 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). ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] A final check on draft-ietf-capport-architecture-09
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 , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Martin Duke's No Objection on draft-ietf-capport-architecture-09: (with COMMENT)
Martin, Thanks again for the review. Responses inline below. On Sun, 9 Aug 2020 at 02:05, Martin Duke via Datatracker wrote: > > Martin Duke has entered the following ballot position for > draft-ietf-capport-architecture-09: No Objection > > -- > COMMENT: > -- > > After further discussion, I see that draft-09 does indeed address my Discuss - > the user-portal-url is optional in practice, just something the api design has > to cover. > > I found the terminology around “Captive Portal API server” and “Captive Portal > Server” to be a little confusing, as these are similar terms. The latter also > doesn’t get its own discussion in Section 2 and is confusingly called the “web > portal server” in Figure 1. > In version 09 we've replaced all mentions of "Captive Portal Server" with User Portal. Similarly, we ensured that we were consistent with its use throughout the document, so "web portal" has become "user portal". > After Figure 1, this seems to be consistently called the “web portal” (sec 2.6 > and 4). In the API doc it is called a "user portal." It would be great to > unify > the terminology across the documents as a whole. We've fixed up the diagram and the document as a whole to use "user portal", which is consistent with the API. > > Thanks again, Kyle ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
[Captive-portals] Martin Duke's No Objection on draft-ietf-capport-architecture-09: (with COMMENT)
Martin Duke has entered the following ballot position for draft-ietf-capport-architecture-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/ -- COMMENT: -- After further discussion, I see that draft-09 does indeed address my Discuss - the user-portal-url is optional in practice, just something the api design has to cover. I found the terminology around “Captive Portal API server” and “Captive Portal Server” to be a little confusing, as these are similar terms. The latter also doesn’t get its own discussion in Section 2 and is confusingly called the “web portal server” in Figure 1. After Figure 1, this seems to be consistently called the “web portal” (sec 2.6 and 4). In the API doc it is called a "user portal." It would be great to unify the terminology across the documents as a whole. ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
