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

[Martin Thomson]

What about those resolvers that collapse CNAME responses, effectively eliding 
them?

I assume that you are going to explicitly say that this has to be directed to 
the resolver provided in network configuration.  If that resolver is outside 
the network or less tightly secured than DHCP/RAs, then we have the possibility 
of attack on the DNS-over-UDP-53 that is used to get the CNAME response.

(Just contributin' not chairin'.)

On Wed, Sep 4, 2019, at 09:44, Lorenzo Colitti wrote:
> 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:///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

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

[Erik Kline]

That's not strictly true (or it needn't be strictly true).

The text in #section-3 as worded allows for a portal that lets the
clear-text query through but still adds the API link rel into the
response.  If the text somehow doesn't allow this, we could make it more
explicit.

If there are 2 equally good ways to do this (DNS and link relation) then it
does, I grant, seem like it would be worth the time to see if the group
could scope it back down to one.

On Tue, 3 Sep 2019 at 18:08, Lorenzo Colitti  wrote:

> If we have a way to discover the portal via DNS, then maybe we don't need
>  at all? The problem with  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  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) 
>> wrote:
>>
>>> I like that idea, combined with well known. Ex:
>>> https:///.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  on behalf of
>>> Lorenzo Colitti 
>>> *Date: *Tuesday, September 3, 2019 at 4:45 PM
>>> *To: *"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:///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

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

[Lorenzo Colitti]

If we have a way to discover the portal via DNS, then maybe we don't need
 at all? The problem with  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  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) 
> wrote:
>
>> I like that idea, combined with well known. Ex:
>> https:///.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  on behalf of
>> Lorenzo Colitti 
>> *Date: *Tuesday, September 3, 2019 at 4:45 PM
>> *To: *"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:///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

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

[Erik Kline]

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) 
wrote:

> I like that idea, combined with well known. Ex:
> https:///.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  on behalf of
> Lorenzo Colitti 
> *Date: *Tuesday, September 3, 2019 at 4:45 PM
> *To: *"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:///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

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

[Cappalli, Tim (Aruba Security)]

I like that idea, combined with well known. Ex: 
https:///.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  on behalf of Lorenzo 
Colitti 
Date: Tuesday, September 3, 2019 at 4:45 PM
To: "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:///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