[14370] 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 (Derek Atkins)
Wed Oct 1 14:16:49 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
To: Guus Sliepen <guus@sliepen.eu.org>
Cc: Eric Rescorla <ekr@rtfm.com>,
Cryptography list <cryptography@metzdowd.com>
From: Derek Atkins <derek@ihtfp.com>
Date: 01 Oct 2003 13:10:04 -0400
In-Reply-To: <20030929191036.GV8599@sliepen.eu.org>
Guus Sliepen <guus@sliepen.eu.org> writes:
> Compared with the entire TLS protocol it is much simpler, compared with
> just the handshake protocol it is about as simple and probably just as
> efficient, but as I said earlier, I want to get rid of the client/server
> distinction.
You can't get rid of the distinction. You will always have a "client"
and a "server" -- however you may just rename it "Initiator" and
"Responder" to make it sound more peer-like, but it's just the same
emperor in different clothes. The only real distinction between a
_pure_ client-server protocol and a peer-to-peer protocol is that the
latter is generally reversible where the former is not. By
"reversible" I mean that either party could be the initiator and
either could be the responder.
HOWEVER, during the run of a protocol it behooves you to label the
parties, and "client/server" is just as valid a naming as
"initiator/responder". IPsec (IKE) is clearly peer/peer. Even with
TLS the protocol is reversible if you perform the name mappings and
assume both ends have certificates.
So, I urge you to be careful with trying to get rid of a distinction
that really has little meaning in most protocols.
-derek
--
Derek Atkins 617-623-3745
derek@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
