New authentication protocol, was Re: Tinc's response to "Linux's answer to MS-PPTP"

[Guus Sliepen]

On Sat, Sep 27, 2003 at 07:58:14PM +0100, M Taylor wrote:

> I hope Guus and Ivo circulate their version 2.0 
> protocol before they do any coding, so that any remaining flaws can be easily 
> fixed in the paper design without changing a single line of code, saving time 
> and effort.

I've been comparing tinc's current authentication protocol with the TLS
handshake protocol as described in draft-ietf-tls-rfc2246-bis-05.txt.
The basic structure is mostly the same: the ID messages in tinc are
TLS's Hello messages, the METAKEY message in tinc is similar to TLS's
RSA encrypted premaster secret message, the ChangeCipherSpec is implicit
in tinc, and tinc's CHALLENGE/RESPONSE messages serve the same purpose
as TLS's finished message (which contains verify_data).

TLS makes a distinction between a client and a server. If possible I
wish to avoid making that distinction. If possible, I would also like to
continue to be able to use an RSA public/private keypair. This made me
*sketch* the following _authentication_ protocol:

==========
Step 1:
Exchange ID messages. An ID message contains the name of the tinc daemon
which sends it, the protocol version it uses, and various options (like
which cipher and digest algorithm it wants to use).

Step 2:
Exchange METAKEY messages. The METAKEY message contains the public part
of a key used in a Diffie-Hellman key exchange.  This message is
encrypted using RSA with OAEP padding, using the public key of the
intended recipient.

After this step, both sides use Diffie-Hellman to compute the shared
secret key. From this master key, keys and IVs for symmetric ciphers and
digest algorithms will be derived, as well as verification data. From
this point on all messages will be encrypted.

Step 3:
Exchange VERIFY messages. The VERIFY message contains verification data
extracted from the master key, so each recipient can verify that the key
exchange went well.

Step 4:
Exchange ACK messages. This will signal each side that the other side
acknowledges the authentication. The ACK message will contain some more
data which has nothing to do with authentication.
==========

I currently think this has none of the problems the current protocol
has, and also makes sure we have perfect forward security (if keys are
renewed using Diffie-Hellman periodically).

Some questions:

- Some people keep saying that "you shouldn't send the same kinds of
  messages". TLS sends different kinds of messages depending on its role
  (client or server). Is there a reason behind this?

- Would it be nice to move all the cryptographic parameters exchanged in
  step 1 into the encrypted message in step 2? That way an attacker
  cannot see which encryption and digest algorithms will be used, which
  might make an attack less feasible.

- Did I miss something?

-- 
Met vriendelijke groet / with kind regards,
    Guus Sliepen <guus at sliepen.eu.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20030929/136006dd/attachment.pgp>