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

[Eric Rescorla]

Guus Sliepen <guus at sliepen.eu.org> writes:
> On Sat, Sep 27, 2003 at 07:58:14PM +0100, M Taylor wrote:
> 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:
I'm trying to figure out why you want to invent a new authentication
protocol rather than just going back to the literature and ripping
off one of the many skeletons that already exist (STS, JFK, IKE,
SKEME, SIGMA, etc.). That would save people from the trouble
of having to analyze the details of your new protoocl.


> ==========
> 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.
Why are you using RSA encryption to authenticate your DH rather
than using RSA signature?

Depending on *exactly* how you do things, there are MITM attacks:

Consider the following protocol:

M1={DHx}RSAy         ->
                    <-              M2={DHy}RSAx
                  
           ZZ = DH shared key

HMAC(ZZ,M1,M2)      ->
                    <-              HMAC(ZZ,M2,M1)     [Reverse order to prevent replay]


Now, the attacker chooses 0 as his DH public. This makes ZZ always
equal to zero, no matter what the peer's DH key is. He can now forge
the rest of the exchange and intercept the connection.

-Ekr
                
-- 
[Eric Rescorla                                   ekr at rtfm.com]
                http://www.rtfm.com/

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com