[EMAIL PROTECTED] (Niels Mvller) writes:
>> > >> 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.
In the context of authentication systems, random passwords are not
usually used at all; some sort of cryptographic exchange is used
instead. With both public-key authenticated ssh and kerberos,
passwords are never given to services. Normally, if you have a
centralized password server, you need an admin to create a new entry
in the database at all, and it doesn't seem like you want that,
either. I think what you want is outside the scope of an
authentication system as they are usually discussed.
What you said was delegating some power to "keys or certificates".
Some application protocols do this, and this is the right way to do
it, not by distributing weak passwords. With AFS (Andrew File
System), I can give any set of afs users (which map roughly onto
kerberos principals) any of {read,write,lock,insert,delete,lock,admin}
permission on a directory and the files contained in it. Users use
their own passwords. There are also groups and metagroups, so I can
create a group marc:friends, and give them write access to a
directory, or give system:authuser (roughly all users in a kerberos
realm) read access to another directory. I believe that cyrus imapd
also has similarly powerful authorization semantics for group
mailboxes.
>> > 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?
The potential for problems can be more limited, but again, most
implementations don't bother.
In kerberos, when you get an initial ticket or a service ticket, it
contains a list of the IP addresses from which it can be used. It
also contains a number of flags. If a ticket has the forwardable flag
set, it can be presented to the kdc, with a new set of addresses and
flags (perhaps including forwardable, or not), and the kdc will send
back this ticket. An application can then forward this ticket to a
remote host.
Normally, the initial ticket is forwarded, such as for login. Then,
the remote login has authentication as the user. If this ticket is
not forwardable, then an attacker on the remote host cannot forward
the ticket. With ssh agent forwarding, there is no way to prevent
this. Also, it is possible to forward only an individual service
ticket. For instance, I could give an ftp server the ticket for a
file service such as AFS, so it could write there on my behalf, but it
could not be used to authenticate to any other service. Expiration
times can also be reduced for forwarded tickets. Forwarded tickets
also have a flag set by the KDC which indicates that they are
forwarded, so a paranoid application server can refuse to accept
forwarded credentials. With ssh, there is no way for a server to
distinguish if the client was given the password, is using a local
ssh-agent, or is using a forwarded ssh agent.
Forwarded tickets also have the advantage and disadvantage that they
can outlive the original ticket, which is useful for scheduling batch
jobs in the future, for instance. The kerberos protocol has a
mechanism for revocation, but it is not complete and not implemented
that I know of.
Marc
