netdev - Re: [RFC] tcp: Initial support for RFC5925 auth option

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3afe618a-e848-83c3-2cc5-6ad66f3ef44b@gmail.com>
Date:   Tue, 27 Jul 2021 21:05:59 +0300
From:   Leonard Crestez <cdleonard@...il.com>
To:     Francesco Ruggeri <fruggeri@...sta.com>,
        David Ahern <dsahern@...il.com>
Cc:     Eric Dumazet <edumazet@...gle.com>,
        "David S. Miller" <davem@...emloft.net>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        Jakub Kicinski <kuba@...nel.org>,
        David Ahern <dsahern@...nel.org>,
        Yuchung Cheng <ycheng@...gle.com>,
        Mat Martineau <mathew.j.martineau@...ux.intel.com>,
        Christoph Paasch <cpaasch@...le.com>,
        Priyaranjan Jha <priyarjha@...gle.com>,
        Kuniyuki Iwashima <kuniyu@...zon.co.jp>,
        Menglong Dong <dong.menglong@....com.cn>,
        open list <linux-kernel@...r.kernel.org>,
        linux-crypto@...r.kernel.org, netdev <netdev@...r.kernel.org>,
        Salam Noureddine <noureddine@...sta.com>,
        Bob Gilligan <gilligan@...sta.com>,
        Dmitry Safonov <dima@...sta.com>
Subject: Re: [RFC] tcp: Initial support for RFC5925 auth option



On 7/27/21 6:05 AM, Francesco Ruggeri wrote:
> Hi Leonard,
> 
> thanks for taking on this task!
> 
>> I'm especially interested in feedback regarding ABI and testing.
> 
> I noticed that the TCP connection identifier is not part of the
> representation of the MKT (tcp_authopt_key_info).
> This could cause some issues if, for example 2 MKTs with different
> <remote IP, remote TCP port> in the TCP connection identifier but same
> KeyID (recv_id) are installed on a socket. In that case
> tcp_authopt_inbound_key_lookup() may not pick the correct MKT for the
> connection. Matching incoming segments only based on recv_id may not
> comply with the RFC.
> I think there may be other cases where TCP connection identifiers may
> be needed to resolve conflicts, but I have to look at your patch in
> more detail.

The RFC doesn't specify what the "tcp connection identifier" needs to 
contains so for this first version nothing was implemented.

Looking at MD5 support in linux the initial commit only supported 
binding keys to addresses and only relatively support was added for 
address prefixes and interfaces. Remote ports still have no effect.

I think adding explicit address binding for TCP-AO would be sufficient, 
this can be enhanced later. The most typical usecase for TCP auth is to 
connect with a BGP peer with a fixed IP address.

As far as I understand this only actually matters for SYN packets where 
you want a single listen socket to accept client using overlapping 
keyids. For an active connection userspace can only add keys for the 
upcoming destination.

> It would be helpful if you could split your patch into smaller
> incremental chunks.

OK