[14329] in cryptography@c2.net mail archive
New authentication protocol, was Re: Tinc's response to "Linux's answer to MS-PPTP"
daemon@ATHENA.MIT.EDU (Guus Sliepen)
Mon Sep 29 09:48:29 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Mon, 29 Sep 2003 14:07:04 +0200
From: Guus Sliepen <guus@sliepen.eu.org>
To: Cryptography list <cryptography@metzdowd.com>
In-Reply-To: <20030927195814.A13877@pull.privacy.nb.ca>
--EdRE1UL8d3mMOE6m
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Sep 27, 2003 at 07:58:14PM +0100, M Taylor wrote:
> I hope Guus and Ivo circulate their version 2.0=20
> protocol before they do any coding, so that any remaining flaws can be ea=
sily=20
> fixed in the paper design without changing a single line of code, saving =
time=20
> 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:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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?
--=20
Met vriendelijke groet / with kind regards,
Guus Sliepen <guus@sliepen.eu.org>
--EdRE1UL8d3mMOE6m
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/eCBkAxLow12M2nsRAtNqAKCFrJ6pLh5C9nmSjq+fyfciuCjBYgCcD1HO
JKC46CBYQVNrdkW8Kc+eT9k=
=ZZ1l
-----END PGP SIGNATURE-----
--EdRE1UL8d3mMOE6m--
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
