https://github.com/anima-wg/brski-cloud/pull/239/files fixes some text based upon the IoTDIR review. But, the entire section on interactions with captive portals could due with some review from the people on this list.
Original text is at: https://www.ietf.org/archive/id/draft-ietf-anima-brski-cloud-15.html#name-captive-portals If you don't want to read the entire document, Figures 1/2 and the time sequence diagrams in section 4 might be enough. If you need more RFC8995 background, there is a 4min screencast at https://brski.org/brski-impls.html, which is watchable at 2x speed. Slightly changed text (as of #239 above) is: ## Captive Portals A Pledge might find itself deployed in a network where a captive portal or an intelligent home gateway that provides access control on all connections is also deployed. Captive portals that do not follow the requirements of Section 1 of {{?RFC8952}} MAY forcibly redirect HTTPS connections. While this is a deprecated practice as it breaks TLS in a way that most users can not deal with, it is still common in many networks. When the Pledge attempts to connect to any Cloud Registrar, an incorrect connection will be detected because the Pledge will be unable to verify the TLS connection to its Cloud Registrar via DNS-ID check Section 6.3 of {{RFC9525}}. That is, the certificate returned from the captive portal will not match. At this point a network operator who controls the captive portal, noticing the connection to what seems a legitimate destination (the Cloud Registrar), MAY then permit that connection. This enables the first connection to go through. {MCR: yes, this seems very optimistic!} The connection is then redirected to the Registrar via 307, or to an EST server via "est-domain" in a voucher. If it is a 307 redirect, then a Provisional TLS connection will be initiated, and it will succeed. The Provisional TLS connection does not do DNS-ID verification ({{RFC9525, Section 6.3}}), so the forced redirection to a captive portal system will not be detected. However, the subsequent BRSKI POST of a voucher request will most likely be met by a 404 or 500 HTTP code. Even if somehow it did work (because the captive portal was in fact an attacker), any returned voucher would not be signed by a trusted MASA. It is RECOMMENDED therefore that the Pledge look for {{?RFC8910}} attributes in DHCP, and if present, use the {{?RFC8908}} API to learn if it is captive. The scenarios outlined here when a Pledge is deployed behind a captive portal may result in failure scenarios, but do not constitute a security risk, so long as the Pledge is correctly verifying all TLS connections as per {{BRSKI}}. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Captive-portals mailing list -- [email protected] To unsubscribe send an email to [email protected]
