Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01

[Joe Touch <[e-mail]>]

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

Hi, Eric (et al.),

We'll have time to discuss these issues in detail later today at the
TCPM meeting. Here is some potential context for that...

Joe

Eric Rescorla wrote:
| $Id: draft-ietf-tcpm-tcp-auth-01-rev.txt,v 1.1 2008/07/28 03:06:22 ekr
Exp $
|
| I've reviewed the latest version of this document and while it
| seems to incorporate some improvements over the -00 version,
| I still have a number of concerns:
|
| - The document seems to assume an (unspecified) external key management
| mechanism. That seems less than maximally useful

The split of this work into separate key management and TCP extension
documents was a prerequisite to the design team's output. The WG chairs
and/or ADs can speak to it more directly.

| - There's discussion of a "per-connection nonce" in S 3.2,
| but it's non-normative and does not completely specify how
| the nonce is to be used:
|
|      MACs typically benefit from a per-connection nonce, notably in
|      avoiding the impact of key reuse. The presence of TCP's pair of
|      Initial Sequence Numbers presents a nonce that may be useful in that
|      case. Such a nonce could be computed as the concatenation of the
ISNs
|      (initiator, responder), and the socket pair (addresses, ports):
|
|      o  Nonce = ISN_i, ISN_r, IP_address_i, IP_address_r, port_i, port_r
|
|      The initial SYN would not know ISN_r, so that packet's nonce would
|      use ISN_r = 0. Use of these nonces avoids the need to avoid key
reuse
|      on a per connection basis.
|
|      >> ISN and socket pair nonces MUST be used to generate unique per-
|      session keys.
|
|    I don't see in the draft where it actually describes how this is
|    intended to work.

The nonce would be used by the external session key management
mechanism. This part of the document may move to that other specification.

| - The discussion of key rollover seems incomplete
|
|       >> TCP-AO implementations SHOULD change keys for a connection at
|       least every 2^31 bytes, to avoid resending segments with the same
|       TCP sequence number, data, and length under the same key.
|
| How is this intended to work?

The key management mechanism should react to sequence numbers rolling
over the ISN (perhaps masking out the high bit to roll over twice as often).

| It seems to me that a useful system needs to describe a complete set
| of mechanisms that allow the establishment of a single static key which
| can be used to secure multiple connections. I don't see that this
| document does that.

This document does not specify a key management mechanism; that
mechanism would use a single static key to generate per-session keys.

| Previous comments which I believe remain outstanding:
| S 1.
|    there have been escalating attacks on the algorithm itself [Be05]
|    [Bu06].  TCP MD5 also lacks both key management and algorithm
|
| These citations should be to the original papers, not the summaries
| (not that I mind you citing Steve's and my paper...)
|
| [New: you've added a cite to Burr's paper, but you should be
| citing Wang et al.]

Thanks - that will be updated.

| S 1.1.
| I don't see a lot of value in pre-specifying two MAC algorithms
| as MTI. There's no reason to believe one isn't plenty, as used
| in other protocols.

The need for two required algorithms mirrors the intent of RFC4305's
"SHOULD+", which requires one, but suggests that two algs may be
required in the future. The design team suggested that requiring two
algorithms now would be prudent, notably so that if one were compromised
(either entirely, or effectively weakened due to computational
exploits), the other would be pre-deployed. The two could also trade
strength for performance, depending on which algorithms are recommended
by SAAG.

| S 2.2.
| Figure 2 is kind of hard to read since the length of the kind
| field is 16 bits, but kinds are 8 bits, rigth?

The length of the field is wide due to the text; that will be fixed to
be proportional to the bit width (8 bits, as you note).

| S 3.
|                >> At least one direction (inbound/outbound) SHOULD have
|                a non-NONE MAC in practice, but this MUST NOT be strictly
|                required by an implementation.
|
| 1. This seems like a bad idea. It's very hard to analyze the security
| properties of a connection when only one side is protected. To take
| one case that is obviously bad, if you're worried about DoS attacks
| and you use TCP-AO, then forging packets in either direction can
| bring it down. I would reverse this and require MACs in both directions.
|
| 2. Even if we stipulate that this might be an OK idea, it's not
| appropriate to require implementations to support it.

We discussed the utility of asymmetry in Philadelphia last March. The
point is to require implementations to allow the user to request
connections configured this way; we can add that connections MUST
default to using a real MAC in both directions by default. Does that
address your concern?

| S 9.
|    TCP-AO does not expose the MAC algorithm used to authenticate a
|    particular connection; that information is kept in the TSAD at the
|    endpoints, and is not indicated in the header.
|
| This seems to be of extremely marginal security benefit. There
| are likely to be <5 algorithms in use. So, searching all of them
| increases the effective key size by <3 bits.
|
| [New: Again, this isn't a security issue]

The text should be updated to note that the primary and sufficient
reason for omitting it is space conservation and the fact that there is
no utility in including it. The number of algorithms doesn't merely
augment the key space, though - it an algorithm is known weak(er),
indicating it in the header is a signal in the clear that the packet
stream is more vulnerable.

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

iEYEARECAAYFAkiNaWgACgkQE5f5cImnZrtTgACg12PIYHDfLrSm4CnTySFFLXSp
EucAn0uZKkNNsMp3axP1gzzO7bDA8wBT
=JOdm
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm