[14331] in cryptography@c2.net mail archive
Re: New authentication protocol, was Re: Tinc's response to "Linux's answer to MS-PPTP"
daemon@ATHENA.MIT.EDU (Eric Rescorla)
Mon Sep 29 10:52:08 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
To: Guus Sliepen <guus@sliepen.eu.org>
Cc: Cryptography list <cryptography@metzdowd.com>
Reply-To: EKR <ekr@rtfm.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: 29 Sep 2003 07:53:29 -0700
In-Reply-To: <20030929120704.GI715@sliepen.eu.org>
Guus Sliepen <guus@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@rtfm.com]
http://www.rtfm.com/
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com