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

[Kyle Rose <[e-mail]>]

On Tue, Oct 3, 2017 at 2:46 PM, David Mazieres expires 2018-01-01 PST
<[e-mail]>
wrote:
>> 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.
>
> 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