[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



If we have a way to discover the portal via DNS, then maybe we don't need <link rel> at all? The problem with <link rel> is that it cannot be used once the portal is open, so if the device logs in, and then disconnects and reconnects, it doesn't work.

On Wed, Sep 4, 2019 at 10:05 AM Erik Kline <[email protected]> wrote:
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) <[email protected]> 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 | @timcappalli

 

From: Captive-portals <[email protected]> on behalf of Lorenzo Colitti <lorenzo=[email protected]>
Date: Tuesday, September 3, 2019 at 4:45 PM
To: "[email protected]" <[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/captive-portals