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

[Guus Sliepen]

On Mon, Sep 29, 2003 at 09:51:20AM -0700, Bill Stewart wrote:

> > =========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).
> 
> By "name of the tinc daemon", do you mean identification information?
> That data should be encrypted, and therefore in step 2.
> (Alternatively, if you just mean "tincd version 1.2.3.4", that's fine.

No, identification information. But still, it's just a name, not a
public key or certificate. It is only used by the receiver to choose
which public key (or certificate etc) to use in Step 2. This information
does not have to be encrypted, it has just as much meaning as the IP
address the sender has.

> > 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.
> 
> You can't encrypt the DH keyparts using RSA unless you first exchange
> RSA public key information, which the server can't do without knowing
> who the client is (the client presumably knows who the server is,
> so you _could_ have the client send the key encrypted to annoy MITMs.)

With tinc, public keys are never exchanged during authentication, they
are known beforehand. And again, there is no distinction between a
client and a server, it is peer to peer.

-- 
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/a0e7af10/attachment.pgp>