[Captive-portals] Re: seeking review comments on revised CAPPORT considerations in brski-cloud

[Tommy Pauly <[e-mail]>]

> On Jun 29, 2025, at 11:52 AM, Michael Richardson <[e-mail]> wrote:
> 
> 
> 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.

I would question using a normative MAY here; clearly, it’s something the network can do and often will do, but it seems like this is more a statement of practice than saying “you MAY do this” as a thing we’d recommend. I would probably say “might”. 

Tommy
> 
>  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 <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> _______________________________________________
> Captive-portals mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> <signature.asc>