Aidan Cully <aidan@kublai.com> writes:
> SSL pro:
>  * Works with any user, anonymous, whatever.
> con:
>  * No authentication support.  The server will need a plaintext copy of
>    your password to authenticate you.

Not actually true. You can authenticate as well as you can with, say,
SSH. It is just the case that most people DON'T use client certs, but
they are fully part of the protocol.

Indeed, extending the protocol very slightly to use ssh-like "certs"
would be trivial, and I'm sure the OpenSSL folks would take back the
code, and the extension could easily be standardized. It would likely
make the world a better place.

> 2228 pro:
>  * Authentication.

Again, SSL does auth.

> con:
>  * you usually need a pre-existing authentication context to use this.
>  * the proposed patch doesn't support SSL out of the box.

My real concern is that security protocols are brittle. It takes a lot
of energy to analyse them. Stealing existing ones means that you have
reasonable assurance of security. New ones are always a threat because
you don't know where the holes might be.

> Kerberos is the best readily available authentication model for use
> within organizations.  You can use scp for copying files instead of
> FTP, but first of all it's a pain to synchronize your public keys on
> all the servers you want to talk to (not just adding to the
> authorized_keys files, but deleting when you don't want to use a key
> anymore.  if you don't use public/private authentication, then you'll
> need to type your password a lot.), and secondly it assumes a login
> account on the host (even if our ftpd appears to want a login account,
> it's still possible to run it inside of a chroot() so that users can
> only use the FTP service).

Solving key management for the SSH universe, of course, might be
readily doable. A key server, for example, would be a straightforward
extension. You can also use Kerberos authentication with SSH, you know.

> As far as I'm concerned, the reasons we want this support (if not
> this patch) are, in this order:
> 1. authentication.
> 2. pain to get an SSL certificate.
> 3. pain to maintain authorized_keys files.
> 4. pain to retype your password all the time.

My current thought is this: it appears, according to Ken and others,
that there are indeed interoperable implementations of this. Given
that, assuming we in fact interoperate, it is reasonable to do
it. However, I'm still not sure it actually is something I would want
to use...

--
Perry E. Metzger		perry@wasabisystems.com
--
NetBSD: The right OS for your embedded design. http://www.wasabisystems.com/