[tcpm] regarding the TCP/MD5 updates

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, all,

There are three documents that currently propose changes to TCP/MD5:

	draft-weis-tcp-auth-auto-ks
	draft-weis-tcp-mac-option
	draft-bonica-tcp-auth

Due to some extraordinary scheduling, I will not be able to participate
in TCPM when these are discussed, so I figured I'd post my comments in
advance.

I've read the three, and my general impression (intended to be
simplistic) is that all three extend TCP/MD5 (RFC2385) as follows:

	draft-weis-tcp-mac-option
		provides for 4 other MACs, all HMACs
			(superset of draft-bonica)

		provides for in-band *rekeying*

		uses the key as 'direct input' to the HMAC,
			rather than as part of the digest

	draft-weis-tcp-auth-auto-ks
		describes the specific mechanism for inband
		rekeying as spected in weis-tcp-mac

	draft-bonica-tcp-auth
		provides for two other MACs, both HMACs

		provides for time-based key rollover
			this seems like a bad idea, and appears
			to be based on the need to rekey

I sincerely hope that the authors of these documents can get together
and document a single, coherent solution. MY requirements for that would be:

	- clear delineation between these and 2385
		I would prefer reuse of option 19 (2385) with use
		of a different length (where 18 refers to the depricated
		2385 version); this would ensure that the new
		TCP auth could not be used where TCP/MD5 is used,
		and would avoid unncessary waste of TCP option space

	- initial session key establishment needs to be addressed

	- algorithm/parameter establishment/agreement needs to be
	addressed

	- I prefer the Weis' IKE-style rekeying to Bonica's time-based
	keys, since the former maps better to TCP semantics and
	would be simpler and more secure to implement (see below)

I would be glad to work with the authors to help accomplish the
following (which I would be glad for them to author, but I have a lot of
interest in making this happen cleanly):

	a) set out a reasonable list of reqiurements
	b) help determine the best way to merge the best
	parts of the existing work to make this happen
	c) help determine how to factor the documents out usefully
	(rather than issuing a single, monolithic doc)

I would prefer this course to having either (or, gasp, both) of these
proposals moving forward independently. I will be glad to meet with the
authors and/or WG chairs interested to help this happen, anytime EXCEPT
during TCPM/INT/BTNS ;-( and TRILL.

Joe

- ---------------------------------------

My specific concerns are as follows:

- - weis-tcp-mac 'direct input' issue
I'm not a cryptographer, but if there's a difference between direct
input and using the key as part of the data to be digested I'd highly
suspect the MAC; this is a subtle issue that is only recently published
and I'd like to	understand if there's consensus in the security
community. It seems like this is more like defining a new HMAC (KMAC?),
at which point it should be defined in a separate document.

- - both docs use both key IDs and alg IDs in the option header
It seems a bad idea to expose the algorithm in the clear, and it seems
unnecessary since a sufficiently large key ID space could be used
instead, where the key ID indicates both the key value and the key
algorithm (i.e., like an SPI does).

- - time-based keying is not a good idea, because TCP has no notion of
absolute time shared between the endpoints, so this needs to rely on NTP
or somesuch as well as TCP, which presents a separate vulnerability, as
well as substantially complicating the TCP implementation.

- - neither document discusses initial keying

- - neither document discusses agreement on algorithm
Perhaps this is because the alg is indicated in the option; it would be
preferable to negotiate this during the connection establishment -
preferably securely (i.e., not in the clear). I see no reason to change
the algorithm during a connection; that could be included in the rekey
exchange without too much extra effort if desired.

- - neither document discusses the initial key exchange
In particular neither document addresses the use of DH for the initial
exchange. There may be concerns about the overhead of DH and the
resulting opportunity for SYN attack, but this should be overcome by
allowing DH to be optional, rather than by ignoring it.

I would also suggest that the initial key exchange allow BTNS-style
unauthenticated DH, i.e.:

	- master-keyed (2385-mode)
	- DH based on master key (authenticated DH)
	- DH without authentication (BTNS mode)

- - both documents discuss 'unused' fields in the proposed option, but
need to be more specific about how that field is handled
	- under the proposed specs, senders MUST set them to zero
	- under the proposed specs, receivers MUST ignore them

- - I would prefer/hope that some of the signalling information between
the endpoints was ALWAYS encrypted, e.g., indicating whether a new key
is enclosed. I don't like the fact that this info is passed in the clear.

- -----------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEGzaVE5f5cImnZrsRAudhAJ41nIIZNphLH8owPevoU8WkHQOq9gCguzAr
LJTjNc3lNuSrk2sN49p6tzc=
=Ow64
-----END PGP SIGNATURE-----

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