Marc Horowitz <[EMAIL PROTECTED]> writes:
> One of the advantages of kerberos is that it can be used easily to
> secure services as well as logins. If B is a chat server run by
> someone I have little trust in, I have no problem using kerberos to
> authenticate to this service. I'm unlikely to want to give it my
> password, and with most chat services, login isn't done.
Good point.
> I've never seen ssh used without a login step. It's not uncommon to
> log into (for instance) a mail server, and use an ssh tunnel to send
> or receive mail, but this doesn't work for all services.
In the ssh2 protocol, it is possible to do user authentication (you
wouldn't want to use ordinary passwd userauth if talking to an
untrusted service), but for a different service than login. I don't
know any implementation that actually does this. Hmm, Datafellow's
sftp probably does just that, but there's no public spec for that as
far as I know. It's also possible to omit the userauth step
completely.
I wrote:
> >> What I really want to to is to give user's the ability to delegate
> >> *some* of her power to certain keys or certificates. For instance, to
> >> access some subset of her files, or run some programs.
>
> This is much more of an OS issue than kerberos vs ssh vs other
> authentication systems issue.
The reason I mentioned it is that it seems incompatible with
centralizing the configuration of authentication methods, to give the
sysadm complete control. To give a concrete example: I may want to
give read-only access to some subdirectory in my $HOME, and to use a
lousy but easy to remember password for that service. Then I wouldn't
want any centralized passwd server to complain about my choice of
password. The "security" here is similar to the usage of readably but
hidden or unlistable directories on a ftp or http-server.
And of course, some delegation can be implemented on the application
level, without any OS-support for it. I do agree that it is mostly
orthogonal to authentication methods, though.
> The former seems less clean than the latter, since ssh is designed to
> handle different authentication protocols. Both would work, though.
> Practically speaking, since ssh ships with the latter implemented,
> it's what I used, often. The ability to combine kerberos
> authentication and ticket forwarding with ssh X and TCP forwarding is
> both secure and convenient.
What is ticket-forwarding (I could guess, but I would prefer a precise
answer from someone who _knows_)? Does it have the same potential
problems as ssh agent forwarding?
/Niels
