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) <t...@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-boun...@ietf.org> on behalf of > Lorenzo Colitti <lorenzo=40google....@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 >
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
