Re: [Cfrg] tcpinc: endpoint authentication and session ID privacy
Kyle Rose <krose@krose.org> Thu, 10 November 2016 21:52 UTC
Return-Path: <krose@krose.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99663129558 for <cfrg@ietfa.amsl.com>; Thu, 10 Nov 2016 13:52:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqcBhphUWS8G for <cfrg@ietfa.amsl.com>; Thu, 10 Nov 2016 13:52:34 -0800 (PST)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6D8B129566 for <cfrg@irtf.org>; Thu, 10 Nov 2016 13:52:33 -0800 (PST)
Received: by mail-qk0-x236.google.com with SMTP id q130so314293730qke.1 for <cfrg@irtf.org>; Thu, 10 Nov 2016 13:52:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BIXdbbmhAmgN5mylk9u83TqlpuQmVU7w+bTIRQ/CyNU=; b=O+e/+wtXO3T8YMiZ8Ulx+ltYqWs7vmBWOIh9EckXodY81QgWNnUJz78xMw85/j3Y1N i9t3Fkl/+UIrS/JxGE9ifjxh+uYCBr/VdBNgC2jlz2F4iLT3WGCteseSxp6n6zYT3BHU wiRwuQgWw9WbD7Hc/PXfs6w+QYtQrT6CjOCCI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BIXdbbmhAmgN5mylk9u83TqlpuQmVU7w+bTIRQ/CyNU=; b=h2JtVMM4PEyOmVac+5eHMnlqVljwf1TBdOSmH4bIhwZaD/eTlZ9+iKuaP4i8s3zSg/ Y3+m9ChJ6/2MDulhSpMfHFAwMPQOLYIfqyoTAOHPLpuOveKt3+AStj655YhnBgDZrOhI RPXeTTTanov0yPUnEncLcXw+xRdQxFnh3eAMHOYv8VleyjynymMSe7NyTto3I6eFBt8e SaiFybR3T1tap24G6E60IyOFPQMY/T7Nd8fMgqOQsYA0QPcSheOBNyjz3KFBEpCgKdKA 9sbmXTTEIj23h2VkgRxp44lWZOWusfCtyw6tgRiO67hbq/vSzPI+sD1qX8wRBGrDuRks Uqxg==
X-Gm-Message-State: ABUngvfIU3E911m88bW26K+FqcvaCRJDIaPMdQYHhyUm0I2mtP8ay1eY16GgCKX3eLsgo3tfdzgfoIvC/fJcKw==
X-Received: by 10.55.24.36 with SMTP id j36mr8967419qkh.268.1478814752923; Thu, 10 Nov 2016 13:52:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.55.180.2 with HTTP; Thu, 10 Nov 2016 13:52:32 -0800 (PST)
X-Originating-IP: [88.128.80.101]
In-Reply-To: <20161001171651.GA8138@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CAJU8_nXtwpe1_8UpKtKnG3fmpMWuMW7Zcj6SzPAnZ9jmJi9T2g@mail.gmail.com> <a78ce42cf3504cbbb35735b0f45bc43b@usma1ex-dag1mb1.msg.corp.akamai.com> <CAJU8_nXXTVYCu+wt5QJ1RZiuqzparFwvQ33J55E-SaLhuZ6GoQ@mail.gmail.com> <20161001171651.GA8138@LK-Perkele-V2.elisa-laajakaista.fi>
From: Kyle Rose <krose@krose.org>
Date: Thu, 10 Nov 2016 16:52:32 -0500
Message-ID: <CAJU8_nWD-u5WauftE795z-D-=LL=mJC=SOCyDXctaZgNJGURBw@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary="001a11429ba2097b880540f96428"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/jhIhh3UoCQ4t-DdHof_NgHIjemU>
Cc: cfrg@irtf.org, tcpinc-chairs@ietf.org
Subject: Re: [Cfrg] tcpinc: endpoint authentication and session ID privacy
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Nov 2016 21:52:36 -0000
Apologies for the 6-week RTT. Now that I'm stuck on a 14 hour flight, I finally have some time to get through the email backlog. On Sat, Oct 1, 2016 at 1:16 PM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote: > On Sat, Oct 01, 2016 at 12:31:31PM -0400, Kyle Rose wrote: > > No: a session ID is to be used on one connection only, with a key > > derivation algorithm used by both hosts on secret IKM to derive future > IDs > > for session caching/reuse. See sections 3.3-3.4 of the tcpcrypt draft for > > more information on how these identifiers are derived. > > I tried reading the relevant sections, and noticed that if SID[i], for > i>0 gets disclosed, one can correlate the resumption attempt. > Not quite sure what you mean here. SID[i] is defined as SID[i] = CPRF (ss[i], CONST_SESSID, K_LEN) where ss[i] is secret for all i, ss[i] chains off ss[i-1], and where ss[i] is used as the IKM for further key derivation within the connection identified by SID[i]: in particular, I think I'm claiming that there's no computation that gets you from SID[a] to SID[b] for a != b. Depending on CPRF, they may or may not be indistinguishable from random to an observer without knowledge of the inputs, but they should have no correlation with each other. So if you reveal SID[a] in one resumption attempt and then SID[b] in a different resumption attempt, that by itself shouldn't help an observer correlate the attempts. > But I presume that the SID value used for identifying the connection is > SID[0]. > A client is supposed to use a particular SID[i] for resumption once only, and then advance to SID[i+1] for the next resumption attempt; and both the client and the server should securely erase ss[i] from memory once it is used to resume a session on a connection so SID[i] cannot be used for subsequent resumption attempts. > Also, the computation formula for PRK has concatenations. One needs to > be careful with concatenations: The components must be uniquely > parseable from concatenation. > Agreed. We think tcpcrypt is okay on this front. In particular: (1) eno-transcript is uniquely parseable despite being of variable length because it incorporates the length via the TCP option length byte, as noted in section 4.8 of the TCP-ENO draft. (2) Init1 and Init2 similarly incorporate the message length. (3) The length of ES doesn't matter given its placement at the end of the input, and while its structure is kex alg-specific, any collision here could occur only if bytes earlier in the input corresponded to a different kex alg: IOW, for a given kex algorithm, it will uniquely parse. Kyle
- [Cfrg] tcpinc: endpoint authentication and sessio… Kyle Rose
- Re: [Cfrg] tcpinc: endpoint authentication and se… Salz, Rich
- Re: [Cfrg] tcpinc: endpoint authentication and se… Kyle Rose
- Re: [Cfrg] tcpinc: endpoint authentication and se… Ilari Liusvaara
- Re: [Cfrg] tcpinc: endpoint authentication and se… Kyle Rose