Don Davis <[EMAIL PROTECTED]> writes: > EKR writes: > > I'm trying to figure out why you want to invent a new authentication > > protocol rather than just going back to the literature ... > > there's another rationale my clients often give for > wanting a new security system, instead of the off- > the-shelf standbys: IPSec, SSL, Kerberos, and the > XML security specs are seen as too heavyweight for > some applications. the developer doesn't want to > shoehorn these systems' bulk and extra flexibility > into their applications, because most applications > don't need most of the flexibility offered by these > systems.
I hear this a lot, but I think that Perry nailed it earlier. SSL, for instance, is about as simple as we know how to make a protocol that does what it does. The two things that are generally cited as being sources of complexity are: (1) Negotiation. (2) Certificates. Negotiation doesn't really add that much protocol complexity, and certificates are kind of the price of admission if you want third party authentication. > some shops experiment with the idea of using only > part of OpenSSL, but stripping unused stuff out of > each new release of OpenSSL is a maintenance hassle. But here's you're talking about something different, which is OpenSSL. Most of the OpenSSL complexity isn't actually in SSL. The way I see it, there are basically four options: (1) Use OpenSSL (or whatever) as-is. (2) Strip down your toolkit but keep using SSL. (3) Write your own toolkit that implements a stripped down subset of SSL (e.g. self-signed certs or anonymous DH). (4) Design your own protocol and then implement it. Since SSL without certificates is about as simple as a stream security protocol can be, I don't see that (4) holds much of an advantage over (3) -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]