[EMAIL PROTECTED] (Niels Mvller) writes:
>> I think one problem with kerberos is that when you want to communicate
>> between to different sites (or realms, in kerberos-speak), the sysadms
>> of those realms must have had some previous contacts, and must have
>> installed a shared key for this realm-pair. Of course, ssh doesn't
>> quite solve this problem either, but the important difference is that
>> ssh at least makes it possible for users to solve the problem for
>> themselves, without any need for cooperation between the respective
>> sysadms.
There are proposals for using public keys for interrealm kerberos.
This still likely requires some contact between realms, but publishing
a public key is much easier than sharing highly sensitive secrets.
>> > (2) Because a host may be compromised it is not acceptable for an
>> > end user's credentials in the form of a password to be sent to
>> > to a host. Sending a password over an encrypted mutually
>> > authenticated channel only prevents the password from being
>> > read in transit. It does not prevent a compromised host from
>> > sending the credentials somewhere else.
>> >
>> > This is solved by Kerberos using the password to communicate
>> > via encrypted messages with a trusted third party. SSH public
>> > key authorization also avoids sending of the password. But
>> > when public key is not being used the password is sent across
>> > the encrypted wire.
Unfortunately, it is common to use ssh agent forwarding with ssh,
which permits an attacker on the compromised target to make use of the
ssh credentials.
>> I think this is a unique feature of kerberos. I see that it can be
>> important under some circumstances, but I don't think that it is
>> crucial in the general case. Consider a site with a central
>> authentication server C (for instance using kerberos), and several
>> hosts. Now, a user sits down at a random host A, and logs in on
>> another host B. Now, A and C will see the user's cleartext password,
>> but not B. So if B was compromised, we're still somewhat safe.
>>
>> But this is quite useless, unless we have some reason to believe that
>> it is a lot less likely that A is compromized than B. Under what
>> circumstances is this true?
>>
>> As far as I can see, the typical case is that A is a machine in an
>> office, a lab or terminal room, and B is some kind of cpu- or
>> file-server. To me it seems a lot easier to ensure the security of B
>> (for example, you want to restrict who can get physical access to the
>> machine) than for A. I.e. the opposite of the above hypothesis seems
>> to be true.
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.
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.
>> But I think kerberos is far from ideal here; I suspect you can mount a
>> dictionary attack [1] after recording some communication between you
>> and the kerberos server (correct me if this is utterly wrong).
There are modifications to the kerberos protocol (EKE, SPEKE, and
variants) which make offline brute-forcing impractical for a passive
attacker. I've never seen a widely deployed implementation,
presumably due to patent issues.
>> And if the local machine is compromized, it may transmit your
>> password to the attacker as you type it. I'm willing to take for
>> granted the security of the local machine, because I don't see how
>> I could get any security at all without it.
This is still true.
>> 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.
>> I'd like ssh to offer the features needed for large organizations. If
>> I can find out how.
>>
>> Two final questions for those of you using kerberos: If you already
>> have kerberos up and running on your site(s), why would you consider
>> using ssh at all? If you want to combine them, would one of the
>> following possibilities suit your needs?
>>
>> * Use kerberos to create an encrypted connection between your
>> machines. Run the ssh connection-protocol on top of that tunnel (i.e.
>> do things like starting shells, forward X and tcp, etc, but don't do
>> any of the ssh style authorization or encryption).
>>
>> * Use ssh, but add an authentication algorithm that lets you login
>> using a kerberos ticket that you obtained earlier.
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.
Marc
