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
On Wed, Aug 07, 2019 at 02:43:35PM -0700, Tommy Pauly wrote:
> 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 protected]> wrote:
> >
> > [ 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
> >
> > _______________________________________________
> > Taps mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/taps
>
--
---
[email protected]
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
