Authentication scheme

[Guus Sliepen]

Hello everybody,

Here are some thoughts about the authentication scheme to be used in tinc. The
current scheme (see CVS version, revision CABAL) does this:

   Client               Server
   ---------------------------------------
   send_id(u)
                        send_challenge(R)
   send_chal_reply(H)
                        send_id(u)
   send_challenge(R)
                        send_chal_reply(H)
   send_metakey(R)
                        send_metakey(R)
   send_ack(u)
                        send_ack(u)
   ---------------------------------------
   Other requests(E)...

   (u) Unencrypted,
   (R) RSA, using public key from the other side
   (H) SHA1,
   (E) Encrypted with symmetric cipher.

Although tinc is peer-to-peer, the client here denotes the tinc server that
makes an outgoing connection, the server is the one that accepts an incoming
connection.

This scheme is very similar to what SSH (secure shell) uses. However, a man in
the middle could relay all messages between the client and the server up to the
exchange of the metakeys. After that, the mitm breaks the connection with the
real client, and sends his own metakey. After that, the mitm can receive
messages from the server. It cannot send any messages though, because the mitm
cannot decrypt the symmetric cipher key that has been sent to it. As a result,
the mitm cannot send or receive any network packets on the VPN. But, since the
server thinks it has a valid connection from the client, this can be used as a
DoS attack.

The real problem here is that the authentication is done before the symmetric
cipher is used. Thus, a better solution would seem to be exchanging metakeys
first, enable the symmetric cipher, and only then do the authentication.

The scheme Wessel Dankers has come up with is the following:

   Client               Server
   ---------------------------------------
   send_id(u)
                        send_id(u)
   send_metakey(R)
                        send_metakey(R)
   send_ping(E)
			send_ping(E)
   send_pong(E)
			send_pong(E)
   ---------------------------------------
   Other requests(E)...

In this scheme, the pings contain a small random number (128 bits or something
like that), which must be returned by a pong. We could also name this challenge
and chal_reply, whatever. The pongs act as an ack here. This scheme has some
advantages:

- A man in the middle cannot fake a pong, since it cannot decrypt the incoming
  metakey, and therefore cannot decrypt the incoming ping.

- The first thing encrypted with the symmetric cipher is a random string, which
  is very good against cryptographic attacks (no known plaintext at the start of
  an encrypted stream).

I cannot see any problems with this scheme. It also looks much cleaner to me.
But, we can never be too sure. If anyone has some suggestions, please mail them!
If not, I suggest we replace the current scheme with Wessel's one.

-------------------------------------------
Met vriendelijke groet / with kind regards,
  Guus Sliepen <guus at sliepen.warande.net>
-------------------------------------------
See also: http://tinc.nl.linux.org/
          http://www.kernelbench.org/
-------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://brouwer.uvt.nl/pipermail/tinc-devel/attachments/20001104/b91f92f4/attachment.pgp