Subject: [Cfrg] tcpinc: endpoint authentication and session ID privacy

From: Kyle Rose <[email-masked]>
Date: Sat, 1 Oct 2016 11:32:07 -0400

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

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 1 Oct 2016 15:48:29 +0000

> 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

Is correlation possible, such as when I move from my NATted home to work?  (Yes, this is a basic/naïve question, sorry.)

---

From: Kyle Rose <[email-masked]>
Date: Sat, 1 Oct 2016 12:31:31 -0400

>
>
> Is correlation possible, such as when I move from my NATted home to
work?  (Yes, this is a basic/naïve question, sorry.)

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.

Kyle

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 1 Oct 2016 20:16:52 +0300

> 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.

But I presume that the SID value used for identifying the connection is
SID[0].

Also, obviously, if one wants to use SID as secret value (AFAICT, SID[0]
qualifies as "secret nonce"), one wants to derive a separate binder for
it if the value of the binder is to be disclosed.

Also, the computation formula for PRK has concatenations. One needs to
be careful with concatenations: The components must be uniquely
parseable from concatenation.

-Ilari