Re: [tcpm] discussion of draft-rescorla-tcp-auth-arch-00.txt

Eric Rescorla <ekr@networkresonance.com> Tue, 11 March 2008 11:54 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: ietfarch-tcpm-archive@core3.amsl.com
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D4D728C37C; Tue, 11 Mar 2008 04:54:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.908
X-Spam-Level:
X-Spam-Status: No, score=-99.908 tagged_above=-999 required=5 tests=[AWL=0.529, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZphyH2UozMQ; Tue, 11 Mar 2008 04:54:43 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFA4728C223; Tue, 11 Mar 2008 04:54:43 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726C33A6A5B for <tcpm@core3.amsl.com>; Tue, 11 Mar 2008 04:54:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K84Vcd85yi-m for <tcpm@core3.amsl.com>; Tue, 11 Mar 2008 04:54:38 -0700 (PDT)
Received: from kilo.rtfm.com (dhcp-11ec.ietf71.ietf.org [130.129.17.236]) by core3.amsl.com (Postfix) with ESMTP id 3B8163A6882 for <tcpm@ietf.org>; Tue, 11 Mar 2008 04:54:38 -0700 (PDT)
Received: from dhcp-1679.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id A85891AB2B9; Tue, 11 Mar 2008 07:52:20 -0400 (EDT)
Date: Tue, 11 Mar 2008 07:52:20 -0400
From: Eric Rescorla <ekr@networkresonance.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <47D5E09A.5000803@isi.edu>
References: <47D5E09A.5000803@isi.edu>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20080311115220.A85891AB2B9@kilo.rtfm.com>
Cc: IETF Security Area WG <saag@mit.edu>, tcpm@ietf.org
Subject: Re: [tcpm] discussion of draft-rescorla-tcp-auth-arch-00.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

At Mon, 10 Mar 2008 18:30:02 -0700,
Joe Touch wrote:
> > Network Working Group                                        E. Rescorla
> > Internet-Draft                                                RTFM, Inc.
> > Intended status:  Informational                           March 09, 2008
> > Expires:  September 10, 2008
> > 
> > 
> >                Notes on TCP Authentication Architectures
> >                   draft-rescorla-tcp-auth-arch-00.txt
> ...
> > 1.  Introduction
> ...
> >    Note that there is currently two documents
> >    [I-D.ietf-tcpm-tcp-auth-opt] [I-D.bellovin-tcpsec] that discuss
> >    additional requirements, but it's not clear to me that these
> >    requirements have consensus or in fact are correct.
> 
> The documents were presented at the last IETF, where we solicited 
> comments on those requirements. The requirements were presented as 
> having the consensus of the TCP-AO design team only at that time.

Sure. I was just trying to say that I wasn't taken them as a given
for the purposes of this document.


> > 3.  Keys and Associations
> > 
> >    Probably the most important architectural question is the
> >    relationship of keys to associations.  As indicated above, TCP MD5
> >    uses a single static key for all associations.  This key is
> >    configured in a pairwise fashion.  By contrast, conventional channel
> >    security protocols such as TLS [RFC4346] or IPsec [RFC4301] establish
> >    a fresh set of keying material for each association.  The proposed
> >    TCP Authentication Option [I-D.ietf-tcpm-tcp-auth-opt] also requires
> >    (though does not arrange for) a fresh key for each association.
> 
> TCP-AO is identical to IPsec [i.e., 4301] in that regard; neither 
> arranges for keys, and both rely on a separate protocol to do so, in the 
> sense that IPsec relies on IKE.

It's similar to IPsec but not identical, in that IPsec's notion of an
association spans multiple TCP connections.


> >       >> New TSAD entries MUST be checked against a table of previously
> >       used TSAD entries, and key reuse MUST be prohibited.
> > 
> >    There are two good (and one not so good) reasons why it's desirable
> >    to have mechanisms for changing keys:
> 
> Changing keys is not related to the above key reuse issue AFAICT.

Well, part of my point in this section is to distinguish these
cases in which one might or might not wish to use different
keys at different times.

> Key changes are to reduce the amount of material signed under a single 
> key, to reduce the utility of signed packets to a cryptoanalyst.

As I indicate in S 3.3, while this is certainly crypto lore for
symmetric ciphers, I am unaware of any evidence that having
large (but practical) numbers of plaintext/ciphertext pairs 
is of any significant value in attacking modern algorithms.

> Key reuse is critical to preventing replay attacks within a connection 
> ID (src IP, dst IP, src port, dst port, aka socket pair). It is useful 
> to avoid keying different ports or even different hosts with the same 
> key, but only in a general sense (i.e., to again reduce the amount of 
> material signed with a single key).

I'm not sure which issue you're referring to here by "within a socket
pair".

- With a single connection.
- Between connections which happen to share parameters by coincidence.

As I indicate in S 3.1, there's no replay issue in the first case
except for TCP sequence number rollover, which can be fixed by
using extended sequence numbers. The relevant issue is the
second case, again discussed in S 3.1, but it's not clear to
me how important this actually is.


> >    o  To arrange for different cryptographic keying material to be used
> >       for each connection, thus preventing cut-and-paste attacks between
> >       connections.  (Good)
> 
> Those don't seem relevant; the ports change, so the signatures would change.

Yes, I'm talking about the second of the two issues above.


> >    o  To limit the amount of plaintext/MAC pairs available to the
> >       attacker (Not-so-good)
> 
> Is that the 'amount of keyed material' kind of stuff above? That was 
> given by Bellovin as an issue with TCP-MD5.

Yes, presumably. As I say, I'm unaware of any cryptographic issue
here.


> >    In TCP, cut-and-paste attacks are also possible within a connection
> >    due to sequence number rollover.  This can be fixed, however, by
> >    extending the sequence numbers virtually, as done with ESP/AH.
> 
> We definitely do not want to tie the keying directly to the sequence 
> space for a variety of reasons (we listed some, I believe); this is done 
> indirectly by bytecounts or packet counts to trigger key changes.

The only mention of sequence number in your draft is in S 9:

   Value (ICV). In TCP-AO, the socket pair performs most of the function 
   of IPsec's SPI, and IPsec's Sequence Number, used to avoid replay 
   attacks, isn't needed due to TCP's Sequence Number, which is used to 
   reorder received segments. Unfortunately, it is not useful to 
   validate TCP's Sequence Number before performing a TCP-AO 
   authentication calculation, because many out-of-window segments still 
   cause TCP protocol actions (e.g., ACK retransmission) [RFC793]. It is 
   similarly not useful to add a separate Sequence Number field to the 
   TCP-AO option, because doing so could cause a change in TCP's 
   behavior even when segments are valid. 

But this is not what I'm talking about. I'm merely talking about
using the ISNs as a diversifier for the per-connection key.
Could you elaborate more on issues with this.


> > 6.2.1.  Internal Key Management Protocol
> > 
> >    The traditional approach to this problem would be to build a KMP into
> >    TCP.  This would presumably entail designing a new crypto protocol
> >    (no small job) which is then carried in a TCP option.
> 
> TCP option space is already consumed by a number of commonly used 
> options, and we want to retain space for additional options where 
> possible. Space is most limited in the SYN packet, which is where the 
> initial key exchange would occur.
> 
> Because there isn't enough TCP option space for this sort of solution, 
> we excluded it as a possibility.

I tend to agree that this is not that attractive an alternative.


> > 6.2.3.  Layered KMP
> > 
> >    Another way to provide a separate KMP is to bind it more tightly to
> >    the transport protocol by running it over (or next to, as in DTLS-
> >    SRTP [I-D.ietf-avt-dtls-srtp]) the transport protocol.  At the time
> >    that the association is created, the application initiating the
> >    association also initiates a KMP exchange over (next to) the
> >    transport protocol.  When the KMP terminates, it outputs keying and
> >    parameter information and imposes them on the association.  In the
> >    case of TLS over TCP, this would look something like:
> > 
> >                TCP Client                              TCP Server
> >                ----------                              ----------
> >                TCP SYN ------------------------------------->
> >                   <---------------------------------- TCP SYN/ACK
> >                TCP ACK ------------------------------------->
> >                   <--------- TLS Handshake (over TCP) ------>
> >         Keys to TCP                                         Keys to TCP
> >                App data (protected with TCP integrity) ----->
> >                <----- App data (protected with TCP integrity)
> 
> This fails to protect the SYN exchange, which we consider a requirement. 

I certainly agree that it does not protect the SYN. I noted it as
the second major disadvantage. As for whether this is a requirement,
I think that's deserving of some discussion.


> It also changes state from non-keyed to keyed; it would be very 
> difficult to introduce that sort of stateful change inside the TCP 
> protocol in ways that affect the data stream, since no other options 
> have that kind of effect (i.e., of affecting all data after some point).

I'm no expert on TCP options and I'm certainly prepared to believe
that no other options have this effect, but I'm not sure I see
the issue here as to why this is a problem. The sides can simply
place the option in the segment keyed with some null key and
algorithm (e.g., all zero MAC) and then start processing when
the key is set. As I recall, a similar algorithm is used in
SCTP-AUTH.

-Ekr
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm