[secdir] review of draft-ietf-tcpm-tcp-auth-opt-10

Radia Perlman <radiaperlman@gmail.com> Sun, 07 March 2010 05:30 UTC

Return-Path: <radiaperlman@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 6893E3A9118; Sat, 6 Mar 2010 21:30:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id GPMozcCips9y; Sat, 6 Mar 2010 21:30:41 -0800 (PST)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com []) by core3.amsl.com (Postfix) with ESMTP id 0D6E93A9073; Sat, 6 Mar 2010 21:30:41 -0800 (PST)
Received: by pwi3 with SMTP id 3so3497827pwi.31 for <multiple recipients>; Sat, 06 Mar 2010 21:30:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=RKM1KaQk5xVNFHPHL2xt4yTIit9qMZez1aSSaMbR2dU=; b=r69758dYwnZIHrhswbVg7dv01Hi5zBdsnm2ZUAYpkU9l2w+RDLZji5M6ytl6HPHsC5 K76sN9ohFquKMR08ZoYfraT2LcUrSFg+1HW3epfSF7hJqdNFq6lwunbu9HtMUE5/M/zg bK0biNVxjJuO3xgbnzTHfsAkX0oKfhl7HSd9g=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=YyRfRhIDWNSv5QGq9Ckhhi3o1YvdMVU5Fz+fB6bHGGdP5SHV3mMtORxhba7tLSdHsQ huIJyeFucW8LQdVMQwzsLnMgWSpPEPiTtjfvXEF0r2UmKh30SaH6uGVXgWfVsXBJEX7Z gyFZoYuRvtp5CzxIqqObvyY235tkYjLX0y97g=
MIME-Version: 1.0
Received: by with SMTP id z6mr2069926wfd.214.1267939841820; Sat, 06 Mar 2010 21:30:41 -0800 (PST)
Date: Sat, 6 Mar 2010 21:30:41 -0800
Message-ID: <c09b97ef1003062130y5c83f334x796ee9243d61fed2@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: iesg@ietf.org, secdir@ietf.org, touch@isi.edu, mankin@psg.com, rbonica@juniper.net
Content-Type: multipart/alternative; boundary=000e0cd154aade4a1604812f3f41
X-Mailman-Approved-At: Sun, 07 Mar 2010 08:14:11 -0800
Subject: [secdir] review of draft-ietf-tcpm-tcp-auth-opt-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Mar 2010 05:30:42 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.
This protocol is essentially a lightweight special purpose version of the
Authentication Header (AH) protocol (RFC 4302). It is intended as a
generalization, improvement, and replacement of the TCP-MD5 protocol
documented in RFC2385. RFC2385 only proposed using TCP-MD5 for BGP, which
had certain unique requirements (like keeping a TCP connection up through
crashes of one or both endpoints). The proposal does not explicitly limit
the applicability.

One question that leaps to mind is why there is both this and AH (not to
mention ESP).

The primary differences between TCP-AO and AH are:

TCP-AO can only be used to protect TCP connections (because the integrity
checksum is included in a TCP extension header).

TCP-AO only increases the packet length by 16 bytes with default crypto (AH
adds 24 bytes with default crypto).

While both are technically independent of any particular keying mechanism,
AH was designed to be keyed using IKE (RFC 4306) while TCP-AO was designed
for manual keying. In particular, TCP-AO includes an in-band protocol for
signally when a new key is available so that when new keys are configured at
the two ends of a connection, both ends will start using the new key only
when it is available at both ends.

Review of the document:

Section 4.2 under KeyID (and repeated in section 5.1 under IDs), the
document says that KeyID values are arbitrary. This is not quite true. The
same KeyID value cannot be used for two different valid keys. (So an
implementation must assure that all nodes have deconfigured or expired keys
with a particular KeyID value before assigning that KeyID value to a new

Section 4.2 also implies that the KeyID for the same master key used to
generate different encryption keys for the two different directions of TCP
can have different KeyIDs in the two different directions. That seems like a
useless generality.

Section 8.1 specifies how to choose the key to use in a next packet based on
the RNextKeyID in the last received packet. It does not specify how to
choose the key when starting a new connection (i.e. sending a SYN). I would
assume that there is some non-connection state saved on the node (and
preserved across crashes) that remembers the last RNextKeyID received on any
connection, and this is used to open new connections. The first time a
connection is opened to a node that has never successfully been connected
to, the sender would cycle through all valid keys until finding one the
other end will accept. In any case, the spec should say.

Section 8.2 paragraph 5 says the implementation of SNEs (extended sequence
numbers) is not specified in this document. This seems entirely
unacceptable, since the two ends must implement them identically for the
protocol to work and they aren't specified anywhere else. Further, it
appears that they *are* specified in the paragraphs that follow (though
stated as an example rather than a spec).

Sections 9.3-9.5 appear to be dealing with the case where one end of the
connection has been configured to use TCP-AO but the other has not. This
should probably be modeled as having a special "no authentication" key
configured as a valid key for the connection. The initiator would not use
that key when sending a SYN, but would switch to that key if he got an
unsigned ACK from the other end or he got an unsigned SYN from the other
end. There is an implication that existing implementations will ignore the
TCP-AO extension if they don't support TCP-AO. Is that true? (When in this
mode, there is no security, but it is a way to add initial keys to the two
endpoints without breaking connectivity during the period when one end has
been keyed and the other has not. Once both ends have received a correctly
signed message from the other end, they should stop accepting unsigned ones.

Section 10 says "TCP implementations MUST support TCP-AO". What does this
mean? Implementations of this spec MUST implement this spec. It is not
reasonable to expect *all* TCP implementations to support TCP-AO.

Section 11.2 suggests use of IPsec NAT traversal instead of TCP-AO if NATs
are present, but does not suggest how that would be negotiated. Or is this
saying that IPsec NAT traversal is preferred in any scenario where NAT
traversal *might* be needed?


Page 4 2nd to last paragraph: There is a badly structured sentence that
could be fixed in multiple ways. One way would be: "This document obsoletes
the TCP MD5 option with a more general TCP Authentication Option (TCP-AO).
The new design supports the use of other (stronger) hash functions, provides
replay protection for long-lived connections and across repeated instances
of a single connection, coordinates key changes between endpoints, and
provides a more structured recommendation for external key management."

Section 3 paragraph 3: "proceeding -> preceding"

Page 13 3rd to last line: "match at exactly" -> "match exactly"

Page 21 3rd to last line: "when is" -> "when it is"