[Cfrg] tcpinc: endpoint authentication and session ID privacy

Kyle Rose <krose@krose.org> Sat, 01 October 2016 15:32 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 D638E12B0CC for <cfrg@ietfa.amsl.com>; Sat, 1 Oct 2016 08:32:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level:
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[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=ham 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 Br49Xu0PfXW8 for <cfrg@ietfa.amsl.com>; Sat, 1 Oct 2016 08:32:09 -0700 (PDT)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 56D9312B01D for <cfrg@irtf.org>; Sat, 1 Oct 2016 08:32:09 -0700 (PDT)
Received: by mail-qk0-x22d.google.com with SMTP id n189so58648585qke.0 for <cfrg@irtf.org>; Sat, 01 Oct 2016 08:32:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=2XrR3qHLucb1AJg+hjUbC7B+2gNa/phFDPb1cDpy6aI=; b=bWyTRWgYoohonLJu0DA2PVAtz3WR23PcyLwsygZBJPapVTzhbLu5DEZA9SWXY/LOlU EaAKUJXpNV/XZME4naCsgJif/ENlNq/Ind2qPtJXtKyLm3YvK3yqpjdweG/7MGSJc6g3 fUl4LQRsz5j/8Ae2a8jE2ZsITdAa2tflrLvOs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=2XrR3qHLucb1AJg+hjUbC7B+2gNa/phFDPb1cDpy6aI=; b=W7Kc2X1DFGBur8BYa2ChybAM/9A4kk02wdy/UY6I7TJ3sbBBimZ9CpIAWSp2bvsciD QZDeC2e54cc2pl+xn0wFn/JCq898MA4WyydSgK3YgoFNyyIBdESrUr3IzjjqK3umxe/u GHq2BAAOU3LiL0sMie7RKgyu1JKABnlxMct5OKeYd9pK2wm85VV5Boq0S58vwppz6Dmv G7cz06eaVfzoVZxEDo+SUia/L3XEEUj15bXfFtzTVKuS4YZyHKLU2/L4Gq45cup6Ed7u MHiWz8kKCk98DKzLxmlRLSN7WZ2JOpkzInlg9lKdbhTEwezQbl1Y7M4vUvX4rVfSBaF5 5qWA==
X-Gm-Message-State: AA6/9RmvDkqDXF8ZVbaHXlxu7fX2DYnf2GWdsl3u8WiCmzV7Rb7lR/q1oEODQzp+i+WfOEpRQaFNXWiMcXNjIQ==
X-Received: by 10.55.19.36 with SMTP id d36mr12216774qkh.247.1475335928316; Sat, 01 Oct 2016 08:32:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.217.8 with HTTP; Sat, 1 Oct 2016 08:32:07 -0700 (PDT)
X-Originating-IP: [64.134.97.173]
From: Kyle Rose <krose@krose.org>
Date: Sat, 01 Oct 2016 11:32:07 -0400
Message-ID: <CAJU8_nXtwpe1_8UpKtKnG3fmpMWuMW7Zcj6SzPAnZ9jmJi9T2g@mail.gmail.com>
To: cfrg@irtf.org
Content-Type: multipart/alternative; boundary="001a113ffee6ee9d95053dcf69db"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/MqSHM0F_aZZ7KMQzG0-thR_yBc8>
Cc: tcpinc-chairs@ietf.org
Subject: [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: Sat, 01 Oct 2016 15:32:11 -0000

In the tcpinc working group we're working hard on finishing up the tcpcrypt
draft. One of the remaining items on my plate is to solicit analysis of
certain aspects of the protocol and to get advice on how best to word some
of the security assertions in the draft. I'm hoping some folks in cfrg can
help out.

The first issue relates to bootstrapping authentication on top of the
opportunistically-encrypted channel that tcpcrypt creates. Endpoint
authentication bootstrapped via tcpcrypt relies on the uniqueness over all
time of a session ID that is computed from a function of inputs (e.g.,
session transcript, output of key agreement) known to both endpoints of a
connection: "[the session ID] will with overwhelming probability be unique
for each individual TCP connection" from https://tools.ietf.org/html/dr
aft-ietf-tcpinc-tcpcrypt-02.

The authors claim (and I am inclined to agree, though I am not a
cryptographer) that these session IDs do not in general need to be private
(e.g., if they are to be signed by private keys known only to the
legitimate endpoints, with that signature used as proof of channel
integrity), only that an attacker in control of one endpoint of a
connection must not be able to manipulate the inputs to the session ID for
a connection with a non-cooperating endpoint in order to produce a
collision in which the ID would be the same on any two different
connections with non-vanishing probability.

First of all: does this achieve the properties we want? Secondly: is there
a straightforward way of explaining why this works in the context of the
protocol as-designed? To this latter point, I'm thinking it has something
to do with the session ID being a collision-resistant function of input
from both endpoints, making it computationally intractable for one endpoint
to influence the outcome in a useful way... but I'm not sure how to word it.

Any thoughts would be greatly appreciated.

Kyle