Subject: Re: [tcpinc] Review of draft-ietf-tcpinc-api-03

From: Kyle Rose <[email-masked]>
Date: Tue, 3 Oct 2017 12:42:31 -0400

On Sat, Sep 30, 2017 at 12:48 AM, David Mazieres
<[email-masked]> wrote:
>> * I don't understand the rationale behind the last bullet in the
>> tcpcrypt section. Is the presumption that an application will
>> authenticate the first connection and then resume without
>> authentication? If so, then it's more than prudent: it MUST purge that
>> session from the cache.
>
> I just got rid of that point.  The idea was that if you somehow
> connected to a man in the middle and think you can avoid it by trying
> again, then you want to flush the cache.  But in practice if you have an
> interception proxy or something that is implementing tcpcrypt, then
> probably trying again isn't going to work.  The point is kind of arcane
> anyway, so no need to try to make it.

SGTM.

> So some BSD have such a sysctl.  For example:
>
>         http://man.openbsd.org/sysctl
>
> I was just trying to be as compatible as possible with that mechanism
> since it exists already.

Sounds good. This was just an informational clarification for me
because for some reason I couldn't find anything about it.

> I didn't understand this comment at the time.  Now I think you just mean
> I used TCP_ENO_LOCAL_NAME which is not a thing.  I've already submitted
> too many drafts tonight, but I fixed this in the git repo, so once we
> settle on everything else I need to fix, the final draft can have this
> fix.

Yes, that's what I meant. I'm not sure why I put it precisely the way I did.

>> * Can you describe for me an attack that would be possible using an
>> authenticator taken out of context? I'm assuming that both ends of the
>> connection with the unique session ID already have the cookie, and
>> that the authenticator would be useless on any other tcpinc connection
>> because of the uniqueness property. Is the issue that the session ID
>> used in the PRF could collide with an entirely distinct (i.e.,
>> non-tcpinc) use? Something similar applies to 5.2, as well.
>
> Yes, say you have a peer-to-peer system where nodes authenticate
> themselves by signing the session ID but not the role.  Then you can
> connect to a server and convince it that it is talking to itself by just
> echoing back the signed message.

Right. This also looks good.

>> * It might be worth pointing out that, in unilateral authentication,
>> the side that does not validate an authenticator relies on the peer
>> ending the connection if validation fails to prevent man-in-the-middle
>> attacks.
>
> I don't really understand this comment.  In unilateral authentication
> one side does not care about whom it is talking to, so why would it need
> to rely on the unknown other side for anything?

What I mean is maybe best illustrated by example. Server-only auth in
TLS provides protection against MitM attacks because the client
authenticates the output of a derivation from some secret that cannot
be engineered by an adversary to be the same on two connections:
modulo a compromise of the signing key or collusion by one of the two
endpoints, this is a proof that with overwhelming probability only the
server and the client know the symmetric key material protecting the
connection. But the server's protection in this case relies on the
client taking action: that is, authenticating the server's certificate
and hanging up if the cert check fails. If not, the MitM can pretend
to be the server to the client, and the server would never know. This
is not true with mutual authentication based on a channel binding, as
either endpoint would be able to distinguish a legit connection from a
broken one.

Kyle

---

From: Kyle Rose <[email-masked]>
Date: Wed, 4 Oct 2017 16:34:40 -0400

On Tue, Oct 3, 2017 at 2:46 PM, David Mazieres expires 2018-01-01 PST
<[email-masked]>
wrote:
> What you are saying is different enough from how I would think of the
> problem that I'm not sure how to process the feedback.  In particular,
> "symmetric keying material" is a layer of abstraction below what should
> be in the security model.  Can you maybe suggest some concrete language
> for the draft?  Maybe there's some missing logical step about how in
> many situations an attack on a client also undermines the server's
> interests?
>
> Or, popping back up a level, is there a mistake someone might make that
> we could plausibly avert by inserting appropriate language about
> unilateral authentication in the draft?  By analogy, things like "always
> check the session ID if you rely on ENO for communications security" and
> "always make sure you have an adequate source of randomness" are good
> reminders.  It sounds like you are suggesting "always make sure your
> anonymous remote clients check the session ID"--but what are servers
> supposed to do about this?  Is there some actionable advice for servers?

The problem is application-layer protocols that falsely assume "I am
the client and am still willing to talk" implies some kind of
authentication of the client or proof of integrity of the
communication channel. It doesn't do either of those: server-only auth
implies only that a properly-working client with access to some
application-layer secret is assured that there is no MitM on its
connection with the server, and so it is safe to use the secret on
this connection without worry about eavesdroppers (as long as the
server is functioning correctly). The server doesn't derive any
knowledge directly from continued communication with the client. The
server can conclude by receiving (for example) a proof of knowledge of
that secret only that the sender has access to the secret, which could
be from (1) a legitimate client, (2) a MitM if the client didn't
perform server auth, or (3) an adversary with access to a compromised
secret. I'll rule out (3) as being analogous to an
incorrectly-functioning server, but that leaves (1) and (2).

It's been a while, but I think I was reacting specifically to the lack
of parallelism between 5.1 and 5.2. 5.1 says:

  q( Each side must verify that the other side's authenticator is correct. )

which mutually authenticates the connection and rules out (2), while 5.2 says:

  q( Whichever side validates an authenticator in this way knows that
the other side belongs to a host that possesses the appropriate
signature key. )

which only authenticates whichever side(s) send signatures and so permits (2).

What I took issue with was that pre-shared key symmetric
authentication and signatures were being treated differently when the
signature mechanism is actually irrelevant to the properties provided
by one-way vs. mutual auth. If this is server-only auth, whether
symmetric or asymmetric, the client must then authenticate itself at
the application layer before the server can safely send it anything
secret.

I think I would probably reword 5.2 to sound more like 5.1, e.g.,
"Each side must verify that the other side's signature is correct",
and then maybe mention that if the client lacks a signature key it
must first authenticate the server and then present an
application-layer authenticator over the channel it knows is secure
before the server can assume anything about the privacy or integrity
of the connection.

Kyle