Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt
"Adam Langley" <agl@imperialviolet.org> Mon, 21 July 2008 19:43 UTC
Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E2E13A6867; Mon, 21 Jul 2008 12:43:25 -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 AA68C3A6867 for <tcpm@core3.amsl.com>; Mon, 21 Jul 2008 12:43:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 tcqA7ebeNkCa for <tcpm@core3.amsl.com>; Mon, 21 Jul 2008 12:43:22 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id AC1163A67DD for <tcpm@ietf.org>; Mon, 21 Jul 2008 12:43:22 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so1215445rvf.49 for <tcpm@ietf.org>; Mon, 21 Jul 2008 12:43:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=KHBAczIDvNp1Ojkfich6CWHEogK/G4/VgZlFerTyVWk=; b=bPLdF49vpnDr/KZV0Xr+odhsw3Uj4NNLoeq1SSLQ5Gv+RYUm3Y1eM1NCw7GSPhe8TQ iNneVcq09Hxo+HeDwsZB7XnR/Z+i0lcfiDGSJK/RGKh3lXyt5XvIZg5q6Vr3hzLXovuF FqjLjijiTPJOKNl6l7GEzqNe8W6Dna8cOTd50=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=dooz6VV+qQmEgKhDxsbM1AxPl9rX1QkgLOI//2BWFCflifjZUoztS/d3kKKtEdB/f1 L21/n86uTp0KuYjOOfRudHOa0r5dpzUn8iHRwz8EY3U4F9g5gHgYtcyAhLTC0Ein5ZY2 Jdn90XsUfHZqGq8ZcGI3RuNWur9gM7rBa4cOU=
Received: by 10.140.139.3 with SMTP id m3mr2065468rvd.38.1216669438108; Mon, 21 Jul 2008 12:43:58 -0700 (PDT)
Received: by 10.141.186.3 with HTTP; Mon, 21 Jul 2008 12:43:58 -0700 (PDT)
Message-ID: <396556a20807211243w673e2638r74b19af48d07e19d@mail.gmail.com>
Date: Mon, 21 Jul 2008 12:43:58 -0700
From: Adam Langley <agl@imperialviolet.org>
To: tcpm@ietf.org
In-Reply-To: <20080714234502.AC4793A69F4@core3.amsl.com>
MIME-Version: 1.0
Content-Disposition: inline
References: <20080714234502.AC4793A69F4@core3.amsl.com>
X-Google-Sender-Auth: b4d9b71577e0b610
Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.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-Archive: <https://www.ietf.org/mailman/private/tcpm>
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
2008/7/14 <Internet-Drafts@ietf.org>: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > Title : The TCP Authentication Option > Author(s) : J. Touch, et al. > Filename : draft-ietf-tcpm-tcp-auth-opt-01.txt An item which I believe is unclear in the spec: Are KeyIDs specific to a single direction? E.g if A and B are transmitting with different keys, could they both call them KeyID 0? At the moment the wording around the TSAD seems to allow this (specifically 6.1). Also, comments on the linux netdev mailing list got me thinking more about key rotation and I think the spec probably needs a sentence or two advising about the use of key rotation. The spec currently suggests that rotation occur every 2**31 bytes sent. It's not clear if the keys for each direction are assumed to rotate independently or not. If the directions are independent then a large one-way transfer allows an attacker to build up a dictionary of valid ACKs. Since the transfer is only one way, the ACKing side will never rotate keys. Thus an attacker could step in and convince the sender that everything was fine even if the true destination was dead. If the keys rotate after 2**31 bytes sent or recved there is a possible window issue. Consider a host which is sending with a very large window over a high delay link. It transmits several key rotations worth of data before the first ack comes back from the other side. Since this ack was elicited by the beginning of the data, it will be transmitted with the first key. If the first key is still active, everything is fine, but if the key window has rotated to the point where old keys are getting evicted then the ACK will be rejected. This currently shouldn't be a problem because the max window size is 1GB, which is less than 2**31 bytes. At some point in the future, if window scaling is allowed to grow past 2**14, then key rotation could limit the window size. Given all these questions, I think the spec should make some advisory remarks. I'm not too sure, but I think I like rotating a per-direction key better. The ACK dictionary attack is unfortunate, but if we aren't having real sequence numbers then our security is limited at best anyway. Based on that I'd suggest a 2-key pair, where, for a half-connection from A to B: B RX enables key 1 at 2**30 bytes received, A switches to key 1 at 2**31 bytes, B RX enables a new key 0 at 2**31 + 2**30 bytes, A switches to new key 0 at 2**32 etc. That would also mean that KeyIDs are specific to a given half-connection. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm
- [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01… Internet-Drafts
- Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-op… Adam Langley
- Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-op… Joe Touch
- Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-op… Adam Langley
- Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-op… Joe Touch
- Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-op… Adam Langley
- Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-op… Joe Touch
- Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-op… Adam Langley
- Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-op… Joe Touch
- Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-op… Adam Langley
- Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-op… Joe Touch
- Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-op… Adam Langley
- Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-op… Joe Touch
- Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-op… Stefanos Harhalakis
- Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-op… Adam Langley
- Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-op… Stefanos Harhalakis
- Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-op… touch
- Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-op… Adam Langley
- Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-op… Joe Touch