Subject: [tcpm] draft-bonica-tcp-auth-04

From: Ron Bonica <[email-masked]>
Date: Wed, 01 Feb 2006 15:21:28 -0500

Folks,

Please review the draft at the following URL:

   http://www.ietf.org/internet-drafts/draft-bonica-tcp-auth-04.txt

An abstract follows:

   "This memo describes a TCP extension that enhances security for BGP,
   LDP and other TCP-based protocols.  It is intended for applications
   where secure administrative access to both the end-points of the TCP
   connection is normally available.  TCP peers can use this extension
   to authenticate messages passed between one another.

   The strategy described herein improves upon current practice, which
   is described in RFC 2385.  Using this new strategy, TCP peers can
   update authentication keys during the lifetime of a TCP connection.
   TCP peers can also use stronger authentication algorithms to
   authenticate routing messages."

                                   Ron

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Sat, 25 Feb 2006 15:51:02 -0800

>    http://www.ietf.org/internet-drafts/draft-bonica-tcp-auth-04.txt

Overall, this document still doesn't address the significant concerns
that Ted and I raised in on the -00 version, in particular, this seems
too much like a patch of TCP/MD5 without addressing the lack of a keying
mechanism.

In particular, it focuses too much (IMO) on time-based key rotation
rather than relying on secure, in-band rekeying.

Some particular comments follow:

key-chain is a TCP-EA data structure, not a TCP one

keys should NOT be used for both inbound and outbound simultaneously

what is the purpose of parsing the TCP header before validating the
segment? (the header has no meaning until validated)

why should routers log errors? they terminate TCP connections only when
acting as hosts anyway; it seems like all hosts should do this

TCP uses state and relative time (timeouts); this protocol uses absolute
time. the document AGAIN fails to discuss the security implications of
relying on absolute time (this was raised at the WG meeting in Vancouver)

	FWIW, RFC3562's reference to key lifetimes is NOT an endorsement
	of using absolute time to change keys; that doc is referring
	to rekeying over time (i.e., sec 16 is incorrect IMO -
	3562 never mentions 'schedules')

	I noted before that time-based keychains are not typical;
	it would be useful to explain why such a complex mechanism
	is being added, rather than a true rekeying protocol (which is
	more typical, and would address initial keying as well)

at least one key selection algorithm MUST be supported. if all MAYs are
dropped, the result MUST (IMO) be complete enough to work

regarding the MAC, are any fields padded if not word-aligned? (that
needs to be noted, either way)

when omitting the TCP options, does that also omit the TCP-EA option?
(it should not)

the algorithm does NOT need to be encoded in the header; the key ID can
easily include that information (like in IPsec)

the header could be much more compact:
	kind 	8 bits
	length	6 bits (40 is max value)
	K-bit	1 bit
	resv'd	1 bit	
		FYI - this MUST be set to zero in current impl's
		AND MUST be ignored on receipt
		("MUST be equal to zero" implies the
		receiver will check it, and that will kill
		its use for extensions)

	IMO, use all 16 bits remaining for the key ID
	(there are performance reasons to make the key ID
	space large and harder to guess off-path; I can discuss this
	at the WG meeting if anyone likes)

sec 11 should be calleed extensions, since this option is already named
an enahancement; however - this section MUST be completed for this doc
to have any impact.

'poor clock sync' is to colloquial; if you depend on clock sync, you need:
	- to discuss how you will establish that with only TCP
		or will this run only in the presence of NTP?
	- to discuss exactly how this depends on NTP

Errors in clock sync ARE errors detected here; that MAY be logged as a
TCP-EA error (otherwise you'll never be able to debug this)

the section on resets is incomplete; if you depend on time, you may
never be able to clean up state even if you have keys. that can affect
the ability to reuse port space. i.e., you may want to add something
that helps TCP-EA connections clean up if idle past when ANY key would
be valid (among other things)

the section on performance is too colloqial, esp. since perfomance is
one of the reasons TCP/MD5 is not widely used. it would help to have
current examples of the impact of performance on utility, even if they
change over time (FWIW, RFC1810 showed how they don't much)

end of sec 12.4 - the remaining octets are for other options (if there
are any others that fit in that space) or for larger hashes in the MACs
of TCP-EA.

sec 12.5 - if this is really intended to force exclusion of TCP/MD5, why
not use the same option number and use a flag to redefine the rest of
the header?

sec 12.6 - this defends against only off-path ICMP attacks; ICMP
messages can still be forged on-path with copies of valid packets and
not be invalidated.

sec 12.8 should be added - to describe relationship to IPsec/IKE

sec 13 changes the valid time of an existing key; that MUST NOT be
permitted, IMO. that sort of thing encourages key reuse, which defeats
the key lifetime issues addressed in RFC3562.

Along those lines, NO KEY should be able to have an expiration time that
is more than a few weeks in the future. in particular, "INFINITY" MUST
NOT be a valid time.