netdev - Re: [RFC 2/2] TCP: Add TCP-AO support

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 for Android: free password hash cracker in your pocket

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

Message-ID: <396556a20807251434n300ca24bw833f51dc0a332676@mail.gmail.com>
Date:	Fri, 25 Jul 2008 14:34:00 -0700
From:	"Adam Langley" <agl@...erialviolet.org>
To:	"YOSHIFUJI Hideaki / 吉藤英明" 
	<yoshfuji@...ux-ipv6.org>
Cc:	netdev@...r.kernel.org
Subject: Re: [RFC 2/2] TCP: Add TCP-AO support

2008/7/18 YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@...ux-ipv6.org>:
> If we can do incremental approach, even if we suppor upto 2 keys,
> I'd suggest something like this:

I've been working some more on this patch. Please take a look at the
new description and see what you think. (The code itself hasn't been
tested enough yet to post):

---start---

The userland interface has changed a lot from the last spin of these patches.
This time we support the full number of different possible keys: 256 RX keys
and a TX key. (You can only have a single TX key at a time.)

Sockets either have no keys, a keyset, or a mapping from IP address to a
keyset. Listening sockets, for example, would probably have the mapping so that
they can have a different key for each authorised host. Connected sockets are
only ever talking to a single host, so doing an IP lookup on each packet is a
waste and the keyset is pointed to directly from the tcp_sock. (Actually, the
two possible pointers: to the keyset and to the IP mapping, are a union and the
LSB denotes which type of pointer it is.)

All the mappings (from IP address and from keynum) are implemented as RB trees.

Keys, in a given keyset, are numbered 0..256. Keys 0..255 are usually RX keys.
When an inbound packet has a keyid of n, key number n is looked up to verify
it. You can also set the TX key number to be in 0..255 if you wish.

Generally however, the TX key number will be 256 and you set the
tx_keyid to determine the keyid advertised on the wire for these keys. Since
the keyid on the wire is only 8-bits, no inbound packet can match against this
key. Since the mapping is a tree, it's efficient to have only key numbers 0,
1, 256.

The expected sequence of operations would be:
  * Add a host, setting the TX key num, MAC function etc
  * Add n keys to that host
  * Add another host etc

Then, when rotating the keys;
  * Set key 256. This changes the TX key immediately.

/* New setsockopts */
/* Takes a tcp_auth_op_host */
#define TCP_AUTH_HOST_ADD	15	/* TCP Auth option: add host */
/* Takes a sockaddr */
#define TCP_AUTH_HOST_DEL	16	/* TCP Auth option: remove host */
/* Takes a tcp_auth_op_key */
#define TCP_AUTH_KEY_SET	17	/* TCP Auth option: set key */

/* MAC functions */
#define TCP_AUTH_KEYED_MD5_128		0
#define TCP_AUTH_HMAC_MD5_96		1
#define TCP_AUTH_HMAC_SHA1_96		2

#define TCP_AUTH_MAX_MAC		2

/* tcpa_flags */
#define TCP_AUTH_RFC2385		(1 << 0)
#define TCP_AUTH_OPTIONS_EXCLUDE	(1 << 1)
#define TCP_AUTH_PSEUDOHEADER_EXCLUDE	(1 << 2)
#define TCP_AUTH_PORT_NUMS_EXCLUDE	(1 << 3)
#define TCP_AUTH_LATCH			(1 << 4)

/* struct tcp_auth_op_host - configuring a new keyset for TCP Auth
 * @tcpa_addr - the address of the host, or 0 for the default keyset
 * @tcpa_flags - see TCP_AUTH_* above
 * @tcpa_macfunc - the MAC algorithm, see TCP_AUTH_* above
 * @tcpa_txkey - the keynum to transmit with
 */
struct tcp_auth_op_host {
	struct __kernel_sockaddr_storage	tcpah_addr;
	__u32					tcpah_flags;
	__u8					tcpah_macfunc;
	__u8					tcpah_reserved;
	__u16					tcpah_txkey;
};

/* struct tcp_auth_op_key - add, delete or replace a key
 * @tcpak_addr - the address of the host to which this key applies
 * @tcpak_keynum - the number of this key.
 * @tcpak_tx_keyid - the keyid of this key on the wire when transmitted
 * @tcpak_keylen - length of the key, in bytes
 * @tcpak_key - the key data follows this structure
 */
struct tcp_auth_op_key {
	struct __kernel_sockaddr_storage	tcpak_addr;
	__u16					tcpak_keynum;
	__u8					tcpak_tx_keyid;
	__u8					tcpak_keylen;
	__u8					tcpak_reserved[4];
	__u8					tcpak_key[0];
};
---

 include/linux/tcp.h      |   68 ++++-
 include/net/tcp.h        |  191 +++++++++-----
 net/ipv4/Kconfig         |    2
 net/ipv4/tcp.c           |  447 ++++++++++++++++++++++++++++++--
 net/ipv4/tcp_input.c     |   13 +
 net/ipv4/tcp_ipv4.c      |  649 +++++++++++++++++++++++++++-------------------
 net/ipv4/tcp_minisocks.c |   44 +--
 net/ipv4/tcp_output.c    |   67 +++--
 net/ipv6/tcp_ipv6.c      |  276 +++++++++++---------
 9 files changed, 1210 insertions(+), 547 deletions(-)

AGL

-- 
Adam Langley agl@...erialviolet.org http://www.imperialviolet.org