Subject: [tcpm] TCP Auth experimental Linux patches

From: "Adam Langley" <[email-masked]>
Date: Fri, 18 Jul 2008 14:32:15 -0700

Since the TCP auth is settling down, I thought that I would try
implementing it to see if any fell out. Others interrested in playing
are welcome to try the patch series[1]. It also includes a netcat like
tool which is capable of configuring TCP auth:
  ./tcp-auth-nc --auth auth:0.0.0.0,password,hmac-md5-96 -l 1234
(server listening on port 1234)
  ./tcp-auth-nc --auth auth:1.2.3.4,password,hmac-md5-96 1.2.3.4 1234
 (client connecting to 1.2.3.4 port 1234)

It's quite a long series and applies against net-2.6 [2]. The first
three patches aren't related to TCP auth and will probably be in
2.6.28. The forth is a search and replace s/md5/auth. The fifth
contains the actual code. Although it doesn't crash on simple
client/server tests I've not tried key rotation etc yet.

Stuff that is clearly a result of the experimental nature of this patch:
  * The TCP option number hasn't been assigned yet, so I just took a guess
  * The MAC functions haven't been decided yet, so I took a guess at
    HMAC-MD5-96 and HMAC-SHA1-96
  * Even if you choose a 96-bit MAC, SACK isn't enabled

Limitations which might well persist into a final patch unless someone has a
good argument against:
  * Only two keys supported (against a spec max of 256)
  * Asymmetric protection not supported

Stuff I included that I hope will end up in the new draft of the spec:
  * The keyid is placed at the beginning of the MAC for better alignment
  * Excluding the pseudoheader and port numbers for NAT traversal is supported

Stuff that might be a good idea, I'm not sure yet:
  * Latch mode: unsigned packets are accepted until the first signed packet is
    received. This is for applications which setup TCP auth after an unsigned
    SYN handshake.

The userspace interface is similar to the md5sig one (and md5sig is still
supported with a wrapper around the TCP auth code) and is probably adequately
described by the header:

#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
#define TCP_AUTH_MAX_MAC_SIZE    20 /* SHA1 sets the limit */

/* tcpa_flags */
#define TCP_AUTH_ALLOW_KEY0      (1 << 0)
#define TCP_AUTH_ALLOW_KEY1      (1 << 1)
#define TCP_AUTH_TX_KEY1      (1 << 2)
#define TCP_AUTH_RFC2385      (1 << 3)
#define TCP_AUTH_OPTIONS_EXCLUDE (1 << 4)
#define TCP_AUTH_PSEUDOHEADER_EXCLUDE  (1 << 5)
#define TCP_AUTH_PORT_NUMS_EXCLUDE  (1 << 6)
#define TCP_AUTH_LATCH        (1 << 7)

struct tcp_auth {
   struct __kernel_sockaddr_storage tcpa_addr;  /* address associated */
   __u8  tcpa_key0[TCP_AUTH_MAXKEYLEN];      /* key0 (binary) */
   __u8  tcpa_key1[TCP_AUTH_MAXKEYLEN];      /* key1 (binary) */
   __u8  tcpa_key0len;           /* key0 length */
   __u8  tcpa_key1len;           /* key1 length */
   __u8  tcpa_macfunc;           /* MAC function */
   __u8  tcpa_flags;
};

[1] http://www.imperialviolet.org/binary/tcp-auth-quilt.tar.bz2
[2] git://git.kernel.org/linux/kernel/git/davem/net-2.6.git

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Adam Langley" <[email-masked]>
Date: Fri, 18 Jul 2008 14:40:39 -0700

On Fri, Jul 18, 2008 at 2:32 PM, Adam Langley <[email-masked]> wrote:
> implementing it to see if any fell out.

I'm sorry, that sentence should be taken out and shot. Please let me try again:

"Since the TCP auth spec is settling down, I thought that I would try
implementing it to see if anything fell out."

Thanks,

---

From: "LANGE Andrew" <[email-masked]>
Date: Mon, 28 Jul 2008 07:56:44 -0500

Adam,

I think it's fantastic that you're working on an implementation of extended tcp auth.  However, I fear your efforts may be misdirected. The reason is that the settled-down spec in draft-bonica, not the one in the tcpm working group draft.  Draft-bonica is implemented, deployed and interops between Alcatel, Cisco and Juniper routers.  Implementing draft-bonica, and testing against the router implementations would be the right direction to pursue.

The reason the traffic on the mailing list has died down it that the tcp-ao draft is stillborn.  It adds nothing the the deployed implementation, except incompatibility on the wire. 

Andrew

-----Original Message-----
From: [email-masked] on behalf of Adam Langley
Sent: Fri 7/18/2008 4:40 PM
To: [email-masked]
Subject: Re: [tcpm] TCP Auth experimental Linux patches

Thanks,

---

From: "Adam Langley" <[email-masked]>
Date: Mon, 28 Jul 2008 09:19:20 -0700

On Mon, Jul 28, 2008 at 5:56 AM, LANGE Andrew
<[email-masked]> wrote:
> I think it's fantastic that you're working on an implementation of extended
> tcp auth.  However, I fear your efforts may be misdirected. The reason is
> that the settled-down spec in draft-bonica, not the one in the tcpm working
> group draft.  Draft-bonica is implemented, deployed and interops between
> Alcatel, Cisco and Juniper routers.  Implementing draft-bonica, and testing
> against the router implementations would be the right direction to pursue.

The draft-bonica is, indeed *very* similar to TCP-AO (the same
cryptographic weaknesses and all, sadly). In fact, I believe that it
would be about an extra dozen lines of code to add support for it.
Since you claim that it has some deployment, that would certainly seem
to be worthwhile to do.

The patch has seen some work since I first posted it and the userspace
interface is now described in [1]. It would be most helpful if you
could review that. I believe that the only difference is that I have
the MAC function as a property of a keyset, not a key. If you are
intending on key rotation also changing the MAC function then that
would have to change.

Cheers,

[1] http://marc.info/?l=linux-netdev&m=121702166623000&w=2

AGL