From nobody Fri Aug 2 01:02:23 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86B41202BE for ; Fri, 2 Aug 2019 01:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQi-ZQgr8ncP for ; Fri, 2 Aug 2019 01:02:16 -0700 (PDT) Received: from magpie.corvid.ch (magpie.corvid.ch [46.101.110.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9961B1202CC for ; Fri, 2 Aug 2019 01:02:15 -0700 (PDT) Received: from [127.0.0.1] (helo=magpie.corvid.ch) by magpie.corvid.ch with esmtp (Exim 4.92) (envelope-from ) id 1htSTr-0000wP-5W for taps@ietf.org; Fri, 02 Aug 2019 08:00:03 +0000 Content-Type: multipart/alternative; boundary="===============3215602777880738762==" MIME-Version: 1.0 From: TAPS WG status robot To: taps@ietf.org Message-Id: Date: Fri, 02 Aug 2019 08:00:03 +0000 Archived-At: Subject: [Taps] Weekly github digest (TAPS GitHub Activity Digest) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 08:02:22 -0000 --===============3215602777880738762== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * ietf-tapswg/api-drafts (+2/-1/=F0=9F=92=AC6) 2 issues created: - Nits on framers in arch-draft (by MaxF12) https://github.com/ietf-tapswg/api-drafts/issues/348 = - "Events" versus "Callbacks" for security-relevant asynchrony (by britra= m) https://github.com/ietf-tapswg/api-drafts/issues/347 [API] [Architectur= e] [discuss] = 2 issues received 6 new comments: - #347 "Events" versus "Callbacks" for security-relevant asynchrony (4 by= philsbln, britram, tfpauly, MaxF12) https://github.com/ietf-tapswg/api-drafts/issues/347 [API] [Architectur= e] [discuss] = - #325 Add support for Property Profiles (2 by philsbln, MaxF12) https://github.com/ietf-tapswg/api-drafts/issues/325 [API] [discuss] = 1 issues closed: - Add support for Property Profiles https://github.com/ietf-tapswg/api-dr= afts/issues/325 [API] [discuss] = Pull requests ------------- * ietf-tapswg/api-drafts (+1/-0/=F0=9F=92=AC1) 1 pull requests submitted: - Fixes #313 per Gorry's comments (by britram) https://github.com/ietf-tapswg/api-drafts/pull/346 = 1 pull requests received 1 new comments: - #346 Fixes #313 per Gorry's comments (1 by britram) https://github.com/ietf-tapswg/api-drafts/pull/346 = Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-tapswg/api-drafts --===============3215602777880738762== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TAPS GitHub Activity Digest)

Friday August 02, 2019

Issues

ietf-tapswg/api-drafts (+2/-1/=F0=9F=92=AC6)

2 issues created:

2 issues received 6 new comments:

1 issues closed:

Pull requests

ietf-tapswg/api-drafts (+1/-0/=F0=9F=92=AC1)

1 pull requests submitted:

1 pull requests received 1 new comments:

Repositories tracked by this digest:

--===============3215602777880738762==-- From nobody Wed Aug 7 08:35:58 2019 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B25F12022E; Wed, 7 Aug 2019 08:35:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: taps@ietf.org Message-ID: <156519215052.8370.18373508294231083698@ietfa.amsl.com> Date: Wed, 07 Aug 2019 08:35:50 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-transport-security-08.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 15:35:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : A Survey of Transport Security Protocols Authors : Christopher A. Wood Theresa Enghardt Tommy Pauly Colin Perkins Kyle Rose Filename : draft-ietf-taps-transport-security-08.txt Pages : 37 Date : 2019-08-07 Abstract: This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog transport services by describing the interfaces required to add security protocols. This survey is not limited to protocols developed within the scope or context of the IETF, and those included represent a superset of features a Transport Services system may need to support. Moreover, this document defines a minimal set of security features that a secure transport system should provide. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-transport-security-08 https://datatracker.ietf.org/doc/html/draft-ietf-taps-transport-security-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transport-security-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 7 13:51:58 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D63120306 for ; Wed, 7 Aug 2019 13:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.201, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wblz9f_hR3C9 for ; Wed, 7 Aug 2019 13:51:54 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286D5120232 for ; Wed, 7 Aug 2019 13:51:53 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 4F61A548028 for ; Wed, 7 Aug 2019 22:51:49 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 3F656440041; Wed, 7 Aug 2019 22:51:49 +0200 (CEST) Date: Wed, 7 Aug 2019 22:51:49 +0200 From: Toerless Eckert To: taps@ietf.org Message-ID: <20190807205149.bad2bvkbj3n5gvzc@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [Taps] TAPS (secure) connection maangement Q X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 20:51:56 -0000 [ 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 nobody Wed Aug 7 14:43:52 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBDA5120116 for ; Wed, 7 Aug 2019 14:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxTUCwhe55yr for ; Wed, 7 Aug 2019 14:43:49 -0700 (PDT) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C407D1200DF for ; Wed, 7 Aug 2019 14:43:49 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x77LfUKJ030195; Wed, 7 Aug 2019 14:43:42 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=IGb/Zo3TwADKROEtIMeXO28AMq9pdv4UA3hU6y6lqLc=; b=a4RdBUeJjTBW13/g3iwj4aFB3WFtv/v+hwnKL0Ryk6rYY2B+iYH2LhjhbV/sOHyHJ0mZ Reo839v9MCDnscm0QsVf7Y6PSg6QmZVLNoZc6l/WreFFEnR2NX8WhqAbLqJxH9UsXABr nAxH9LvmJaTRfxTHVyhT4f03nAzGy3hnBDhyDZ7UyUXpCznzJnKyEkGBlsg7rjj/SLy4 17UsJp5c4p9gOmp2Lksdo9vgxVaj6qMYGMcqmHvcf6ugF6i6p2ghvZ2sh/aiVR/UDc77 u1eh+Xv7sI8rkCHZDd18uTzdfwYFOBsT4y3D7hhBaK93XtvnHZ9z3UKotpa+0yyxOIb+ 4g== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2u56undq39-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 07 Aug 2019 14:43:42 -0700 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PVV006IQZ0SF8G0@ma1-mtap-s02.corp.apple.com>; Wed, 07 Aug 2019 14:43:42 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PVV00C00YVNU500@nwk-mmpp-sz09.apple.com>; Wed, 07 Aug 2019 14:43:41 -0700 (PDT) X-Va-A: X-Va-T-CD: 1d5a643f0bb9eb08f62ba4dedb474f19 X-Va-E-CD: 7e9be8822e98b75cf8f96a9172ae7362 X-Va-R-CD: 8cd832951c4f1d7c383929d24eb89455 X-Va-CD: 0 X-Va-ID: 429600d5-3134-4677-afa3-f22f6dace4c3 X-V-A: X-V-T-CD: 1d5a643f0bb9eb08f62ba4dedb474f19 X-V-E-CD: 7e9be8822e98b75cf8f96a9172ae7362 X-V-R-CD: 8cd832951c4f1d7c383929d24eb89455 X-V-CD: 0 X-V-ID: a767173b-bc33-452c-b52a-a3d9980e00e7 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-08-07_06:,, signatures=0 Received: from [17.234.34.61] by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PVV00AK4Z0T4K40@nwk-mmpp-sz09.apple.com>; Wed, 07 Aug 2019 14:43:41 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_103BE246-70F8-4A5D-BF83-31D7E0BF460F" MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) Date: Wed, 07 Aug 2019 14:43:35 -0700 In-reply-to: <20190807205149.bad2bvkbj3n5gvzc@faui48f.informatik.uni-erlangen.de> Cc: taps@ietf.org To: Toerless Eckert References: <20190807205149.bad2bvkbj3n5gvzc@faui48f.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-07_06:, , signatures=0 Archived-At: Subject: Re: [Taps] TAPS (secure) connection maangement Q X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 21:43:52 -0000 --Apple-Mail=_103BE246-70F8-4A5D-BF83-31D7E0BF460F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 :=3D 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_op= tions_set_verify_?language=3Dobjc = https://developer.apple.com/documentation/network/security_options?languag= e=3Dobjc 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 wrote: >=20 > [ 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. ] >=20 > 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. >=20 > 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). >=20 > 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=20= > in the sate machinery of the transport protocol that no unnecessary > steps are performed (e.g.: exactly NOT the above mentioned connect & > drop behavior). >=20 > Thanks! > Toerless >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_103BE246-70F8-4A5D-BF83-31D7E0BF460F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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#sectio= n-5.3.2.

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

   TrustCallback :=3D 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=3Dobjc
https://developer.apple.com/documentation/network/security_opti= ons?language=3Dobjc

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 <tte@cs.fau.de> = 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
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

= --Apple-Mail=_103BE246-70F8-4A5D-BF83-31D7E0BF460F-- From nobody Thu Aug 8 12:32:16 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA0A120177 for ; Thu, 8 Aug 2019 12:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.201, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1P1UVg16JQG1 for ; Thu, 8 Aug 2019 12:31:59 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6515312013B for ; Thu, 8 Aug 2019 12:31:59 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 6530854800E; Thu, 8 Aug 2019 21:31:54 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 55400440041; Thu, 8 Aug 2019 21:31:54 +0200 (CEST) Date: Thu, 8 Aug 2019 21:31:54 +0200 From: Toerless Eckert To: Tommy Pauly Cc: taps@ietf.org Message-ID: <20190808193154.fp5hytpdbxcs5bb6@faui48f.informatik.uni-erlangen.de> References: <20190807205149.bad2bvkbj3n5gvzc@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Taps] TAPS (secure) connection maangement Q X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 19:32:15 -0000 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 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 > > Taps@ietf.org > > https://www.ietf.org/mailman/listinfo/taps > -- --- tte@cs.fau.de From nobody Thu Aug 8 14:28:02 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294E4120086 for ; Thu, 8 Aug 2019 14:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.478 X-Spam-Level: X-Spam-Status: No, score=0.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, MISSING_MIMEOLE=1.899, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwPabmo85RKd for ; Thu, 8 Aug 2019 14:27:59 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.242]) by ietfa.amsl.com (Postfix) with ESMTP id B163D120098 for ; Thu, 8 Aug 2019 14:27:58 -0700 (PDT) Received: from [IPv6:2001:16b8:5c97:4a00:a9f8:f9a4:ef24:cd6e] (unknown [IPv6:2001:16b8:5c97:4a00:a9f8:f9a4:ef24:cd6e]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id 99E5A593; Thu, 8 Aug 2019 23:27:56 +0200 (CEST) Date: Thu, 08 Aug 2019 23:27:56 +0200 Message-ID: X-Android-Message-ID: In-Reply-To: <20190808193154.fp5hytpdbxcs5bb6@faui48f.informatik.uni-erlangen.de> From: Max Franke To: Toerless Eckert Cc: Tommy Pauly , taps@ietf.org Importance: Normal X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Taps] TAPS (secure) connection maangement Q X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 21:28:01 -0000 PGRpdiBkaXI9J2F1dG8nPjxkaXY+SGkgVG9lcmxlc3MsPC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxi cj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+YXQgdGhlIG1vbWVudCB5b3UgY291bGQgZm9yY2UgeW91 ciBsaXN0ZW5lciB0byBvbmx5IGFjY2VwdCBjb25uZWN0aW9ucyBmcm9tIHNwZWNpZmljIElQIGFk ZHJlc3NlcyBieSBzZXR0aW5nIGEgcmVtb3RlRW5kcG9pbnQgb24gdGhlIFByZWNvbm5lY3Rpb24g YmVmb3JlIGNhbGxpbmcgbGlzdGVuKCkuJm5ic3A7PC9kaXY+PGRpdiBkaXI9ImF1dG8iPlRob3Vn aCBJIGFncmVlIHRoYXQgaXQgbWlnaHQgaW5kZWVkIGJlIGdvb2QgaWRlYSB0byBhbHNvIG1ha2Ug aXQgcG9zc2libGUgdG8gcHJvdmlkZSBhIGJsYWNrbGlzdCBvZiBzcGVjaWZpYyBJUHMgZnJvbSB3 aGljaCB5b3UgZG9udCB3YW50IGFjY2VwdCBjb25uZWN0aW9ucy48YnI+PGRpdiBjbGFzcz0iZ21h aWxfZXh0cmEiIGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIiBk aXI9ImF1dG8iPkJlc3Q8L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSIgZGlyPSJhdXRvIj5N YXg8L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSIgZGlyPSJhdXRvIj48YnI+PGRpdiBjbGFz cz0iZ21haWxfcXVvdGUiIGRpcj0iYXV0byI+QW0gMDguMDguMjAxOSAyMTozMSBzY2hyaWViIFRv ZXJsZXNzIEVja2VydCAmbHQ7dHRlQGNzLmZhdS5kZSZndDs6PGJyIHR5cGU9ImF0dHJpYnV0aW9u Ij48YmxvY2txdW90ZSBjbGFzcz0icXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3Jk ZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48cCBkaXI9Imx0ciI+VGhh bmtzIFRvbW15LAo8YnI+Cgo8YnI+CkkgY291bGRuJ3QgcXVpdGUgZmlndXJlIG91dCBmcm9tIHRo ZSBzcGVjIHdoYXQgY29udGV4dC9wYXJhbWV0ZXJzCjxicj4Kd291bGQgYmUgbWFkZSBhdmFpbGFi bGUgdG8gdGhlIGNhbGxiYWNrLgo8YnI+Cgo8YnI+CkFsc286IGkgd291bGQgYmUgd29ycmllZCBh Ym91dCBub3QgaGF2aW5nIHRoZSBjYWxsYmFjayBvcHRpb24gZm9yCjxicj4KdGhlIGNsaWVudCBJ UCBhZGRyZXNzIGNoZWNraW5nLiBKdXN0IHRoaW5rIG9mIGFsbCB0aGUgYXBwcyAKPGJyPgpkb2lu ZyBHZW9CbG9ja2luZyAodmlkZW8gc3RyZWFtaW5nKSBvciB2ZXJpZnlpbmcgY2xpZW50IEROUwo8 YnI+CmRvbWFpbiBmb3IgbGlzdCBvZiBzdWJzY3JpYmVycyAoYWNhZGVtaWMgcGFwZXJzIGNvbWUg dG8gbWluZCkuCjxicj4KSSBkb24ndCB0aGluayB5b3UgYWx3YXlzIHdhbnQgdG8gZm9yY2UgdGhl IHNlcnZlciBzb2Z0d2FyZQo8YnI+CmRldmVsb3BlciB0byBjYWxjdWxhdGUgc3VjaCBhIGxvbmcg QUNMIHVwZnJvbnQuIEl0IG1pZ2h0IGJlCjxicj4KcHJlZmVycmVkIGluIGhpZ2gtcGVyZm9ybWFu Y2UgY2FzZXMsIGJ1dCB0aGUgbW9zdCBzaW1wbGUgc2VydmVyCjxicj4Kd291bGQgZG8gdGhpcyBv bi1kZW1hbmQuCjxicj4KCjxicj4KQ2hlZXJzCjxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7IFRvZXJs ZXNzCjxicj4KCjxicj4KT24gV2VkLCBBdWcgMDcsIDIwMTkgYXQgMDI6NDM6MzVQTSAtMDcwMCwg VG9tbXkgUGF1bHkgd3JvdGU6Cjxicj4KJmd0OyBIaSBUb2VybGVzcywKPGJyPgomZ3Q7IAo8YnI+ CiZndDsgVGhhbmtzIGZvciB0aGUgcXVlc3Rpb25zISBEZWZpbml0ZWx5IGFuIGludGVyZXN0aW5n IHRvcGljLgo8YnI+CiZndDsgCjxicj4KJmd0OyBJIHRoaW5rIHdoYXQgeW91J3JlIHRyeWluZyB0 byBnZXQgYXQsIGNoZWNraW5nIHRoZSBjbGllbnQncyBhdXRoZW50aWNhdGlvbiBwcm9wZXJ0aWVz IG9uIHRoZSBzZXJ2ZXIsIGlzIGRlc2NyaWJlZCBoZXJlOiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi10YXBzLWludGVyZmFjZS0wNCNzZWN0aW9uLTUuMy4yLgo8YnI+CiZn dDsgCjxicj4KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IFRydXN0IHZlcmlmaWNhdGlv biBjYWxsYmFjazogSW52b2tlZCB3aGVuIGEgUmVtb3RlIEVuZHBvaW50J3MKPGJyPgomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRydXN0IG11c3QgYmUgdmFsaWRhdGVk IGJlZm9yZSB0aGUgaGFuZHNoYWtlIHByb3RvY29sIGNhbiBwcm9jZWVkLgo8YnI+CiZndDsgCjxi cj4KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBUcnVzdENhbGxiYWNrIDo9IE5ld0NhbGxiYWNrKHsK PGJyPgomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8vIEhhbmRsZSB0cnVzdCwg cmV0dXJuIHRoZSByZXN1bHQKPGJyPgomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH0pCjxicj4KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyBTZWN1cml0eVBhcmFtZXRlcnMuU2V0VHJ1c3RWZXJpZmljYXRp b25DYWxsYmFjayh0cnVzdENhbGxiYWNrKQo8YnI+CiZndDsgCjxicj4KJmd0OyAKPGJyPgomZ3Q7 IFRoZSBpZGVhIGhlcmUgaXMgdGhhdCB3aGVuIHlvdSBjb25maWd1cmUgVExTIG9wdGlvbnMgb24g eW91ciBMaXN0ZW5lciBvYmplY3QsIHlvdSBjYW4gY29uZmlndXJlIG9wdGlvbmFsIGV2ZW50IGNh bGxiYWNrcyB0byBwYXJ0aWNpcGF0ZSBpbiB0aGUgY2VydGlmaWNhdGUgY2hlY2tpbmcsIHRodXMg YWxsb3dpbmcgdGhlIGNoZWNrIHRvIG9jY3VyIHByaW9yIHRvIHRoZSBUTFMgaGFuZHNoYWtlIGFj dHVhbGx5IGNvbXBsZXRpbmcuCjxicj4KJmd0OyAKPGJyPgomZ3Q7IEluIHRoZSBBcHBsZSBpbXBs ZW1lbnRhdGlvbiwgd2UgZG8gdGhpcyB3aXRoIGEgY2FsbCAic2VjX3Byb3RvY29sX29wdGlvbnNf c2V0X3ZlcmlmeV9ibG9jayIsIGRvY3VtZW50ZWQgaGVyZToKPGJyPgomZ3Q7IAo8YnI+CiZndDsg aHR0cHM6Ly9kZXZlbG9wZXIuYXBwbGUuY29tL2RvY3VtZW50YXRpb24vc2VjdXJpdHkvMjk3NjI4 OS1zZWNfcHJvdG9jb2xfb3B0aW9uc19zZXRfdmVyaWZ5Xz9sYW5ndWFnZT1vYmpjCjxicj4KJmd0 OyBodHRwczovL2RldmVsb3Blci5hcHBsZS5jb20vZG9jdW1lbnRhdGlvbi9uZXR3b3JrL3NlY3Vy aXR5X29wdGlvbnM/bGFuZ3VhZ2U9b2JqYwo8YnI+CiZndDsgCjxicj4KJmd0OyBSZWxhdGVkIHRv IHRoaXMsIHdlIHJlY2VudGx5IGhhZCBhbiBpc3N1ZSB3ZSB3ZXJlIGRpc2N1c3NpbmcgYXJvdW5k IGFsbG93aW5nIHRoZSBhcHBsaWNhdGlvbiB0byBmaWx0ZXIgYSBjb25uZWN0aW9uIHByaW9yIHRv IGFjY2VwdGluZyBUQ1Agb24gYSBzZXJ2ZXIsIGluIHRoZSBhY2NlcHQgcGF0aCAoaHR0cHM6Ly9n aXRodWIuY29tL2lldGYtdGFwc3dnL2FwaS1kcmFmdHMvaXNzdWVzLzMzOCkuIFRoaXMgdHlwZSBv ZiBldmVudCB3b3VsZCAqb25seSogYWxsb3cgbG9va2luZyBhdCB0aGUgY2xpZW50IElQIGFkZHJl c3MsIGFuZCB3b3VsZG4ndCBoZWxwIGZvciBsb29raW5nIGF0IHRoZSBUTFMgY2VydGlmaWNhdGUu IFdlIGRldGVybWluZWQgdGhhdCBmb3IgdGhlIFRDUCBjYXNlLCB0aGVyZSBjYW4gb2Z0ZW4gYmUg YSB3YXkgdG8gcHVzaCBkb3duIGZpcmV3YWxsIHR5cGUgcnVsZXMgaW4gdGhlIHN5c3RlbSwgYW5k IGRvaW5nIHRoaXMgYXMgYSBwZXItYWNjZXB0IGNhbGxiYWNrIG1heSBub3QgYmUgdGhlIGJlc3Qg bW9kZWwuCjxicj4KJmd0OyAKPGJyPgomZ3Q7IFRoYW5rcywKPGJyPgomZ3Q7IFRvbW15Cjxicj4K Jmd0OyAKPGJyPgomZ3Q7ICZndDsgT24gQXVnIDcsIDIwMTksIGF0IDE6NTEgUE0sIFRvZXJsZXNz IEVja2VydCAmbHQ7dHRlQGNzLmZhdS5kZSZndDsgd3JvdGU6Cjxicj4KJmd0OyAmZ3Q7IAo8YnI+ CiZndDsgJmd0OyBbIFNvcnJ5IGZvciBiZWluZyBsYXp5IGFuZCBhc2sgZXZlbiB0aG91Z2ggaSBo YXZlbid0IHJlYWQgYWxsIHRoZSBkb2N1bWVudHMuCjxicj4KJmd0OyAmZ3Q7Jm5ic3A7IElmIHRo ZSBxdWVzdGlvbiBpcyBhbnN3ZXJzIGJ5IHNvbWUgZXhpc3RpbmcgdGV4dC90aHJlYWQsIHBscy4g bGV0IG1lIGtub3cuIF0KPGJyPgomZ3Q7ICZndDsgCjxicj4KJmd0OyAmZ3Q7IFByZWN1cnNvciBx dWVzdGlvbjogU2VydmVyIGZvciBUQ1AgY29ubmVjdGlvbnMgd2FudHMgdG8gYmUgYWJsZSB0bwo8 YnI+CiZndDsgJmd0OyBkeW5hbWljYWxseSByZWplY3QgY29ubmVjdGlvbiByZXF1ZXN0cyBiYXNl ZCBvbiB0aGUgY2xpZW50cyBjb25uZWN0aW9uCjxicj4KJmd0OyAmZ3Q7IHBhcmFtZXRlcnMsIGUu Zy46IGNsaWVudCBJUC1hZGRyZXNzLiBEeW5hbWljIG1lYW5pbmcgdGhhdCB0aGUgc2VydmVyCjxi cj4KJmd0OyAmZ3Q7IHNob3VsZCBnZXQgYSBub3RpZmljYXRpb24vY2FsbGJhY2ssIGJlIGFibGUg dG8gZXhhbWluZSB0aGUgcGFyYW1ldGVycwo8YnI+CiZndDsgJmd0OyBhbmQgZGVjaWRlLiBBa2E6 IG5vIHByZWRlZmluZWQgcG9saWN5IG9iamVjdCB0aGF0IGNhbiBub3QgcnVuIHNlcnZlcgo8YnI+ CiZndDsgJmd0OyBjb2RlIGF0IHRoZSB0aW1lIG9mJm5ic3A7IHJlY2VpdmluZyB0aGUgY2xpZW50 IGNvbm5lY3Rpb24gcmVxdWVzdC4KPGJyPgomZ3Q7ICZndDsgCjxicj4KJmd0OyAmZ3Q7IEkgZG8g bm90IGV2ZW4gcmVtZW1iZXIgd2h0IHRoZSBiZXN0IGN1cnJlbnQgUE9TSVggc29ja2V0IEFQSSBp cyB0byBkbwo8YnI+CiZndDsgJmd0OyB0aGlzIHRvZGF5LiBUcmFkaXRpb25hbGx5LCBzZXJ2ZXJz IHN1Y2sgYXQgdGhpcywgYmVjYXVzZSB0aGV5IHVzZSBhbgo8YnI+CiZndDsgJmd0OyBhY2NlcHQo KSwgc28gdGhlIGNvbm5lY3Rpb24gaXMgZXN0YWJsaXNoZWQsIGFuZCB0aGVuIHRoZXkgaW1tZWRp YXRlbHkKPGJyPgomZ3Q7ICZndDsgY2xvc2UgdGhlIGNvbm5lY3Rpb24gb25jZSB0aGV5IGhhdmUg cmV0cmlldmVkIHRoZSBjbGllbnRzIElQLWFkZHJlc3MKPGJyPgomZ3Q7ICZndDsgKGdldHBlZXJu YW1lIG9yIHRoZSBsaWtlKS4KPGJyPgomZ3Q7ICZndDsgCjxicj4KJmd0OyAmZ3Q7IFNvLCB0aGUg YWN0dWFsIHF1ZXN0aW9uIGlzIHByZXR0eSBtdWNoIHRoZSBzYW1lIGV4Y2VwdCB0aGF0IGkgZG9u J3QgY2FyZQo8YnI+CiZndDsgJmd0OyBhYm91dCB0aGUgY2xpZW50IElQLWFkZHJlc3MgYnV0IGZv ciBUTFMgY29ubmVjdGlvbnMgaW4gdGhlIGFiaWxpdHkgZm9yCjxicj4KJmd0OyAmZ3Q7IHRoZSBj bGllbnQtc2lkZSB0byBleGFtaW5lIHRoZSBzZXJ2ZXIgY2VydGlmaWNhdGUgcHJlc2VudGVkIGFu ZCB0aGUKPGJyPgomZ3Q7ICZndDsgc2VydmVyLXNpZGUgdG8gZXhhbWluZSB0aGUgY2xpZW50LXNp ZGUgY2V0aWZpY2F0ZSBwcmVzZW50ZWQgLSBhbmQgaW4KPGJyPgomZ3Q7ICZndDsgYm90aCBjYXNl cyBoYXZlIHRoZSBob29rIGZvciB0aGlzIG5vdGlmaWNhdGlvbi9jYWxsYmFjayBlYXJseSBlbm91 Z2ggCjxicj4KJmd0OyAmZ3Q7IGluIHRoZSBzYXRlIG1hY2hpbmVyeSBvZiB0aGUgdHJhbnNwb3J0 IHByb3RvY29sIHRoYXQgbm8gdW5uZWNlc3NhcnkKPGJyPgomZ3Q7ICZndDsgc3RlcHMgYXJlIHBl cmZvcm1lZCAoZS5nLjogZXhhY3RseSBOT1QgdGhlIGFib3ZlIG1lbnRpb25lZCBjb25uZWN0ICZh bXA7Cjxicj4KJmd0OyAmZ3Q7IGRyb3AgYmVoYXZpb3IpLgo8YnI+CiZndDsgJmd0OyAKPGJyPgom Z3Q7ICZndDsgVGhhbmtzIQo8YnI+CiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBUb2VybGVz cwo8YnI+CiZndDsgJmd0OyAKPGJyPgomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KPGJyPgomZ3Q7ICZndDsgVGFwcyBtYWlsaW5nIGxpc3QK PGJyPgomZ3Q7ICZndDsgVGFwc0BpZXRmLm9yZwo8YnI+CiZndDsgJmd0OyBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RhcHMKPGJyPgomZ3Q7IAo8YnI+Cgo8YnI+Ci0tIAo8 YnI+Ci0tLQo8YnI+CnR0ZUBjcy5mYXUuZGUKPGJyPgoKPGJyPgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwo8YnI+ClRhcHMgbWFpbGluZyBsaXN0Cjxicj4K VGFwc0BpZXRmLm9yZwo8YnI+Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dGFwcwo8YnI+CjwvcD4KPC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48L2Rpdj48L2Rpdj48L2Rpdj4= From nobody Fri Aug 9 06:06:33 2019 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E87FE120074; Fri, 9 Aug 2019 06:06:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Aaron Falk via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Cc: philipp@tiesel.net, iesg-secretary@ietf.org, taps-chairs@ietf.org, Philipp Tiesel , taps@ietf.org Message-ID: <156535599094.16044.10296134172411315106.idtracker@ietfa.amsl.com> Date: Fri, 09 Aug 2019 06:06:30 -0700 Archived-At: Subject: [Taps] Publication has been requested for draft-ietf-taps-transport-security-08 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 13:06:31 -0000 Aaron Falk has requested publication of draft-ietf-taps-transport-security-08 as Informational on behalf of the TAPS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ From nobody Mon Aug 12 15:35:29 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D592F120959 for ; Mon, 12 Aug 2019 15:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcnttn-KTjpl for ; Mon, 12 Aug 2019 15:35:22 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D436F120124 for ; Mon, 12 Aug 2019 14:31:00 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B9770548014; Mon, 12 Aug 2019 23:30:54 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id A7B00440041; Mon, 12 Aug 2019 23:30:54 +0200 (CEST) Date: Mon, 12 Aug 2019 23:30:54 +0200 From: Toerless Eckert To: Max Franke Cc: Tommy Pauly , taps@ietf.org Message-ID: <20190812213054.6t4a3dpl2gw2aurs@faui48f.informatik.uni-erlangen.de> References: <20190808193154.fp5hytpdbxcs5bb6@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Taps] TAPS (secure) connection maangement Q X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 22:35:26 -0000 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: >
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 <tte@cs.fau.de>:

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 <tte@cs.fau.de> 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 >
> > > Taps@ietf.org >
> > > https://www.ietf.org/mailman/listinfo/taps >
> > >
> >
> -- >
> --- >
> tte@cs.fau.de >
> >
> _______________________________________________ >
> Taps mailing list >
> Taps@ietf.org >
> https://www.ietf.org/mailman/listinfo/taps >
>

>

From nobody Thu Aug 22 06:50:53 2019 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBA712008A; Thu, 22 Aug 2019 06:50:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: aaron.falk@gmail.com, magnus.westerlund@ericsson.com, taps-chairs@ietf.org, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156648185130.14859.10952588223537192048.idtracker@ietfa.amsl.com> Date: Thu, 22 Aug 2019 06:50:51 -0700 Archived-At: Subject: [Taps] taps - New Meeting Session Request for IETF 106 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 13:50:52 -0000 A new meeting session request has just been submitted by Aaron Falk, a Chair of the taps working group. --------------------------------------------------------- Working Group Name: Transport Services Area Name: Transport Area Session Requester: Aaron Falk Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: MAPRG, PANRG, HTTPBIS Technology Overlap: QUIC, TLS, TSVAREA, TSVWG, TCPM, ICCRG coinrg Key Participant Conflict: IRTFOPEN, RMCAT, AVTCORE, MOPS, LOOPS , mboned, secdispatch, mops, tsvwg, IPPM People who must be present: Colin Perkins Aaron Falk Michael Welzl Magnus Westerlund Gorry Fairhurst Brian Trammell Zaheduzzaman Sarker Mirja Kuehlewind Anna Brunstrom Tommy Pauly Kyle Rose Christopher A. Wood Jake Holland Philipp S. Tiesel Theresa Enghardt Resources Requested: Special Requests: The IRTF Chair is a contributor to TAPS so please avoid IRTF RGs if possible. --------------------------------------------------------- From nobody Fri Aug 23 01:02:20 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C86120143 for ; Fri, 23 Aug 2019 01:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlGPSL9lC5TN for ; Fri, 23 Aug 2019 01:02:17 -0700 (PDT) Received: from magpie.corvid.ch (magpie.corvid.ch [46.101.110.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E03071200CD for ; Fri, 23 Aug 2019 01:02:16 -0700 (PDT) Received: from [127.0.0.1] (helo=magpie.corvid.ch) by magpie.corvid.ch with esmtp (Exim 4.92) (envelope-from ) id 1i14UN-00075C-RH for taps@ietf.org; Fri, 23 Aug 2019 08:00:03 +0000 Content-Type: multipart/alternative; boundary="===============0290054490090958998==" MIME-Version: 1.0 From: TAPS WG status robot To: taps@ietf.org Message-Id: Date: Fri, 23 Aug 2019 08:00:03 +0000 Archived-At: Subject: [Taps] Weekly github digest (TAPS GitHub Activity Digest) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 08:02:19 -0000 --===============0290054490090958998== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * ietf-tapswg/api-drafts (+0/-1/=F0=9F=92=AC2) 1 issues received 2 new comments: - #336 Send() -> Sent<> mapping underspecified (2 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/336 [API] [ready for t= ext] = 1 issues closed: - Send() -> Sent<> mapping underspecified https://github.com/ietf-tapswg/= api-drafts/issues/336 [API] [ready for text] = Pull requests ------------- * ietf-tapswg/api-drafts (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - Address review comments on architecture draft (by tfpauly) https://github.com/ietf-tapswg/api-drafts/pull/349 = Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-tapswg/api-drafts --===============0290054490090958998== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TAPS GitHub Activity Digest)

Friday August 23, 2019

Issues

ietf-tapswg/api-drafts (+0/-1/=F0=9F=92=AC2)

1 issues received 2 new comments:

1 issues closed:

Pull requests

ietf-tapswg/api-drafts (+1/-0/=F0=9F=92=AC0)

1 pull requests submitted:

Repositories tracked by this digest:

--===============0290054490090958998==-- From nobody Fri Aug 30 01:02:17 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F4F120113 for ; Fri, 30 Aug 2019 01:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwGgdyRptU1L for ; Fri, 30 Aug 2019 01:02:14 -0700 (PDT) Received: from magpie.corvid.ch (magpie.corvid.ch [46.101.110.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD83312001A for ; Fri, 30 Aug 2019 01:02:13 -0700 (PDT) Received: from [127.0.0.1] (helo=magpie.corvid.ch) by magpie.corvid.ch with esmtp (Exim 4.92) (envelope-from ) id 1i3bpC-0006OU-Nc for taps@ietf.org; Fri, 30 Aug 2019 08:00:02 +0000 Content-Type: multipart/alternative; boundary="===============6922475582289191748==" MIME-Version: 1.0 From: TAPS WG status robot To: taps@ietf.org Message-Id: Date: Fri, 30 Aug 2019 08:00:02 +0000 Archived-At: Subject: [Taps] Weekly github digest (TAPS GitHub Activity Digest) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 08:02:16 -0000 --===============6922475582289191748== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Pull requests ------------- * ietf-tapswg/api-drafts (+1/-1/=F0=9F=92=AC0) 1 pull requests submitted: - Allow setting new connection limits for inbound connections (by tfpauly) https://github.com/ietf-tapswg/api-drafts/pull/350 = 1 pull requests merged: - Address review comments on architecture draft https://github.com/ietf-tapswg/api-drafts/pull/349 [Architecture] = Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-tapswg/api-drafts --===============6922475582289191748== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TAPS GitHub Activity Digest)

Friday August 30, 2019

Pull requests

ietf-tapswg/api-drafts (+1/-1/=F0=9F=92=AC0)

1 pull requests submitted:

1 pull requests merged:

Repositories tracked by this digest:

--===============6922475582289191748==--