Subject: [Taps] TAPS (secure) connection maangement Q

From: Toerless Eckert <[email-masked]>
Date: Wed, 7 Aug 2019 22:51:49 +0200

[ Sorry for being lazy and ask even though i haven't read all the documents.
  If the question is answers by some existing text/thread, pls. let me know. ]

Precursor question: Server for TCP connections wants to be able to
dynamically reject connection requests based on the clients connection
parameters, e.g.: client IP-address. Dynamic meaning that the server
should get a notification/callback, be able to examine the parameters
and decide. Aka: no predefined policy object that can not run server
code at the time of  receiving the client connection request.

I do not even remember wht the best current POSIX socket API is to do
this today. Traditionally, servers suck at this, because they use an
accept(), so the connection is established, and then they immediately
close the connection once they have retrieved the clients IP-address
(getpeername or the like).

So, the actual question is pretty much the same except that i don't care
about the client IP-address but for TLS connections in the ability for
the client-side to examine the server certificate presented and the
server-side to examine the client-side cetificate presented - and in
both cases have the hook for this notification/callback early enough 
in the sate machinery of the transport protocol that no unnecessary
steps are performed (e.g.: exactly NOT the above mentioned connect &
drop behavior).

Thanks!
    Toerless

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 07 Aug 2019 14:43:35 -0700

Hi Toerless,

Thanks for the questions! Definitely an interesting topic.

I think what you're trying to get at, checking the client's authentication properties on the server, is described here: https://tools.ietf.org/html/draft-ietf-taps-interface-04#section-5.3.2.

   o  Trust verification callback: Invoked when a Remote Endpoint's
      trust must be validated before the handshake protocol can proceed.

   TrustCallback := NewCallback({
     // Handle trust, return the result
   })
   SecurityParameters.SetTrustVerificationCallback(trustCallback)

The idea here is that when you configure TLS options on your Listener object, you can configure optional event callbacks to participate in the certificate checking, thus allowing the check to occur prior to the TLS handshake actually completing.

In the Apple implementation, we do this with a call "sec_protocol_options_set_verify_block", documented here:

https://developer.apple.com/documentation/security/2976289-sec_protocol_options_set_verify_?language=objc
https://developer.apple.com/documentation/network/security_options?language=objc

Related to this, we recently had an issue we were discussing around allowing the application to filter a connection prior to accepting TCP on a server, in the accept path (https://github.com/ietf-tapswg/api-drafts/issues/338). This type of event would *only* allow looking at the client IP address, and wouldn't help for looking at the TLS certificate. We determined that for the TCP case, there can often be a way to push down firewall type rules in the system, and doing this as a per-accept callback may not be the best model.

Thanks,
Tommy

> On Aug 7, 2019, at 1:51 PM, Toerless Eckert <[email-masked]> wrote:
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 8 Aug 2019 21:31:54 +0200

Thanks Tommy,

I couldn't quite figure out from the spec what context/parameters
would be made available to the callback.

Also: i would be worried about not having the callback option for
the client IP address checking. Just think of all the apps 
doing GeoBlocking (video streaming) or verifying client DNS
domain for list of subscribers (academic papers come to mind).
I don't think you always want to force the server software
developer to calculate such a long ACL upfront. It might be
preferred in high-performance cases, but the most simple server
would do this on-demand.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Max Franke <[email-masked]>
Date: Thu, 08 Aug 2019 23:27:56 +0200

Hi Toerless,

at the moment you could force your listener to only accept connections from specific IP addresses by setting a remoteEndpoint on the Preconnection before calling listen().

Though I agree that it might indeed be good idea to also make it possible to provide a blacklist of specific IPs from which you dont want accept connections.

Best

Max

Am 08.08.2019 21:31 schrieb Toerless Eckert <[email-masked]>:

Thanks Tommy,

would do this on-demand.

Cheers

Toerless

--

---

[email-masked]

Taps mailing list

[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 12 Aug 2019 23:30:54 +0200

Max,

as i tried to explain in my last reply, my preferred API would be to
have a functional callback at the appropriate stage of the
connection establishment to check the source-ip address dynamically
and then proceed with connection establishment or reject it.

Cheers
    Toerless

On Thu, Aug 08, 2019 at 11:27:56PM +0200, Max Franke wrote:
> <div dir='auto'><div>Hi Toerless,</div><div dir="auto"><br></div><div dir="auto">at the moment you could force your listener to only accept connections from specific IP addresses by setting a remoteEndpoint on the Preconnection before calling listen().&nbsp;</div><div dir="auto">Though I agree that it might indeed be good idea to also make it possible to provide a blacklist of specific IPs from which you dont want accept connections.<br><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto">Best</div><div class="gmail_extra" dir="auto">Max</div><div class="gmail_extra" dir="auto"><br><div class="gmail_quote" dir="auto">Am 08.08.2019 21:31 schrieb Toerless Eckert &lt;[email-masked]&gt;:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Thanks Tommy,
> <br>
> 
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> &nbsp;&nbsp;&nbsp; Toerless
> <br>
> 
> <br>
> <br>
> &gt; Hi Toerless,
> <br>
> &gt; 
> <br>
> &gt; Thanks for the questions! Definitely an interesting topic.
> <br>
> &gt; 
> <br>
> &gt; I think what you're trying to get at, checking the client's authentication properties on the server, is described here: https://tools.ietf.org/html/draft-ietf-taps-interface-04#section-5.3.2.
> <br>
> &gt; 
> <br>
> &gt;&nbsp;&nbsp;&nbsp; o&nbsp; Trust verification callback: Invoked when a Remote Endpoint's
> <br>
> &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; trust must be validated before the handshake protocol can proceed.
> <br>
> &gt; 
> <br>
> &gt;&nbsp;&nbsp;&nbsp; TrustCallback := NewCallback({
> <br>
> &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // Handle trust, return the result
> <br>
> &gt;&nbsp;&nbsp;&nbsp; })
> <br>
> &gt;&nbsp;&nbsp;&nbsp; SecurityParameters.SetTrustVerificationCallback(trustCallback)
> <br>
> &gt; 
> <br>
> &gt; 
> <br>
> &gt; The idea here is that when you configure TLS options on your Listener object, you can configure optional event callbacks to participate in the certificate checking, thus allowing the check to occur prior to the TLS handshake actually completing.
> <br>
> &gt; 
> <br>
> &gt; In the Apple implementation, we do this with a call "sec_protocol_options_set_verify_block", documented here:
> <br>
> &gt; 
> <br>
> &gt; https://developer.apple.com/documentation/security/2976289-sec_protocol_options_set_verify_?language=objc
> <br>
> &gt; https://developer.apple.com/documentation/network/security_options?language=objc
> <br>
> &gt; 
> <br>
> &gt; Related to this, we recently had an issue we were discussing around allowing the application to filter a connection prior to accepting TCP on a server, in the accept path (https://github.com/ietf-tapswg/api-drafts/issues/338). This type of event would *only* allow looking at the client IP address, and wouldn't help for looking at the TLS certificate. We determined that for the TCP case, there can often be a way to push down firewall type rules in the system, and doing this as a per-accept callback may not be the best model.
> <br>
> &gt; 
> <br>
> &gt; Thanks,
> <br>
> &gt; Tommy
> <br>
> &gt; 
> <br>
> &gt; &gt; On Aug 7, 2019, at 1:51 PM, Toerless Eckert &lt;[email-masked]&gt; wrote:
> <br>
> &gt; &gt; 
> <br>
> &gt; &gt; [ Sorry for being lazy and ask even though i haven't read all the documents.
> <br>
> &gt; &gt;&nbsp; If the question is answers by some existing text/thread, pls. let me know. ]
> <br>
> &gt; &gt; 
> <br>
> &gt; &gt; Precursor question: Server for TCP connections wants to be able to
> <br>
> &gt; &gt; dynamically reject connection requests based on the clients connection
> <br>
> &gt; &gt; parameters, e.g.: client IP-address. Dynamic meaning that the server
> <br>
> &gt; &gt; should get a notification/callback, be able to examine the parameters
> <br>
> &gt; &gt; and decide. Aka: no predefined policy object that can not run server
> <br>
> &gt; &gt; code at the time of&nbsp; receiving the client connection request.
> <br>
> &gt; &gt; 
> <br>
> &gt; &gt; I do not even remember wht the best current POSIX socket API is to do
> <br>
> &gt; &gt; this today. Traditionally, servers suck at this, because they use an
> <br>
> &gt; &gt; accept(), so the connection is established, and then they immediately
> <br>
> &gt; &gt; close the connection once they have retrieved the clients IP-address
> <br>
> &gt; &gt; (getpeername or the like).
> <br>
> &gt; &gt; 
> <br>
> &gt; &gt; So, the actual question is pretty much the same except that i don't care
> <br>
> &gt; &gt; about the client IP-address but for TLS connections in the ability for
> <br>
> &gt; &gt; the client-side to examine the server certificate presented and the
> <br>
> &gt; &gt; server-side to examine the client-side cetificate presented - and in
> <br>
> &gt; &gt; both cases have the hook for this notification/callback early enough 
> <br>
> &gt; &gt; in the sate machinery of the transport protocol that no unnecessary
> <br>
> &gt; &gt; steps are performed (e.g.: exactly NOT the above mentioned connect &amp;
> <br>
> &gt; &gt; drop behavior).
> <br>
> &gt; &gt; 
> <br>
> &gt; &gt; Thanks!
> <br>
> &gt; &gt;&nbsp;&nbsp;&nbsp; Toerless
> <br>
> &gt; &gt; 
> <br>
> &gt; &gt; _______________________________________________
> <br>
> &gt; &gt; Taps mailing list
> <br>
> &gt; &gt; [email-masked]
> <br>
> &gt; &gt; https://www.ietf.org/mailman/listinfo/taps
> <br>
> &gt; 
> <br>
> 
> <br>
> -- 
> <br>
> ---
> <br>
> [email-masked]
> <br>
> 
> <br>
> <br>
> <br>
> <br>
> <br>
> </p>
> </blockquote></div><br></div></div></div>