Re: [Captive-portals] Discovering captive portal API URL via DNS?

Chair hat off, co-author hat on.

We can certain craft some text to round out
https://tools.ietf.org/html/draft-ietf-capport-rfc7710bis-00#section-4 when
the time comes.  Certainly DHCP/RA would retain highest precedence.

RFC 7553 URI records would obviate the inevitable discussion about the
merits of .well-known (I know nothing about .well-known/ except that it
tends to bring up some (.)well-known responses).

Where would you slot DNS results relative to link relation in an HTTP
intercept/redirect?

On Tue, 3 Sep 2019 at 17:32, Cappalli, Tim (Aruba Security) <timc@hpe.com>
wrote:

> I like that idea, combined with well known. Ex:
> https://<targetofcname>/.well-known/capport-api/xyz
>
>
>
> Ideally there would be some standardized precedence order as there are
> different cases for each of these. An example would be a common DNS a
> service that doesn’t have views-like functionality so the ability to return
> a different value based on the source IP/subnet may not be possible. In
> this case, the operator may have control of DHCP and could use 7710.
>
>
>
> Tim
>
>
>
>
>
> *Tim Cappalli* *|* Identity & Policy Architect *|* Aruba Security
> <https://www.arubanetworks.com/products/security/> *|* @timcappalli
> <https://twitter.com/timcappalli>
>
>
>
> *From: *Captive-portals <captive-portals-bounces@ietf.org> on behalf of
> Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
> *Date: *Tuesday, September 3, 2019 at 4:45 PM
> *To: *"captive-portals@ietf.org" <captive-portals@ietf.org>
> *Subject: *[Captive-portals] Discovering captive portal API URL via DNS?
>
>
>
> All,
>
>
>
> During discussions with captive portal operators about implementing the
> capport API, one of the stumbling blocks that keeps coming up is that the
> captive portal operator does not always control the DHCP configuration and
> thus cannot easily use RFC7710.
>
>
>
> The WG has previously rejected the option of using a well-known DNS name
> to discover the URL, because the API itself requires TLS, and without a
> hostname it is not possible (or at least not easy) to validate the server.
> However, what if the client did a CNAME query for capport.arpa (or
> equivalent other local-only, non-DNSSEC-signed name), got back a CNAME for
> the real server, and then assumed that the API server was
> https://<targetofcname>/capport-api ?
>
>
>
> Alternatively, Erik and Warren suggest RFC 7553. In this scheme the client
> would do a URI lookup for "capport.arpa" or equivalent, and would take the
> result of that URL as the API endpoint.
>
>
>
> Thoughts?
>
>
>
> Regards,
>
> Lorenzo
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
>