>> I generally avoid using password authentication to Debian hosts, *except* in
>> the particular case of scp'ing files from one Debian host to another because

> That being said we are evaluating means
> that will allow simple file transfers.

> - install sendfile/saft on all machines so you can do
> sendfile foo.tar.gz weasel@merkel
>
> The crypto stuff could be alleviated by using ipsec between all our
> servers. But that works even less well than you'd expect.

> - setup afs
>
> pros: + AFS is cool

> + once we have a krb realm we could maybe also use it for other
> stuff like all those web services that require logins. How
> good is krb support in browsers these days?

>On Sat, Aug 30, 2008 at 02:32:08PM +0200, Peter Palfrader wrote:

>> + once we have a krb realm we could maybe also use it for other
>> stuff like all those web services that require logins. How
>> good is krb support in browsers these days?

>
>Firefox supports it in a whitelist approach. However I never tested it.

> On Sat, Aug 30, 2008 at 02:32:08PM +0200, Peter Palfrader wrote:

>> - install sendfile/saft on all machines so you can do
>> sendfile foo.tar.gz weasel@merkel
>>
>> The crypto stuff could be alleviated by using ipsec between all our
>> servers. But that works even less well than you'd expect.

>
> The machines needs to check DNSSEC or the names can be spoofed which
> makes ipsec mood.

> On Sat, 30 Aug 2008, Bastian Blank wrote:

>> On Sat, Aug 30, 2008 at 02:32:08PM +0200, Peter Palfrader wrote:

>>> The crypto stuff could be alleviated by using ipsec between all our
>>> servers. But that works even less well than you'd expect.

>> The machines needs to check DNSSEC or the names can be spoofed which
>> makes ipsec mood.

> Or you use only resolvers that you have a trusted (i.e. ipsec)
> connection to and those need to have a complete axfr'ed zone.

>>> What other options did we forget?

>>
>> - Setup Kerberos, allow it as an additional ssh login variant

>
> Circumvents the entire idea behind this exercise: Assuming an attacker
> already has control over one host we want to make it as hard as possible
> for them to jump to other hosts.

>> Or you use only resolvers that you have a trusted (i.e. ipsec)
>> connection to and those need to have a complete axfr'ed zone.

>
> Then we can drop the whole ud-ldap thing and use centralized
> authentication.

> - setup afs
>
> Using AFS would allow us to use a shared /afs/debian.org tree on all
> our systems. AFS does all the magic crypto stuff so you don't have to
> worry about Eve sniffing or Mallory tampering with packets.
>
> Setting up AFS is a big chunk of work. It would require us first to
> setup a kerberos realm, to integrate it into ud-ldap so that new krb
> principals are created with ud-ldap users, and that ud-ldap users can
> set krb passwords, which probably should be different from their ldap
> password.
>
> On the user side once logged in you'd have to get a kerberos ticket
> using your krb password, then alog to get access to your
> /afs/debian.org/transfer/$user or whatever.
>
> We will not put homedirs onto AFS (that would completely torpedo the
> initial goal), it would simply provide a transfer area.
> ...

> What other options did we forget?

>> + once we have a krb realm we could maybe also use it for other
>> stuff like all those web services that require logins. How
>> good is krb support in browsers these days?

> Pretty good. Konqueror supports it out of the box, iceweasel only
> requires you to edit the 'network.negotiate-auth.trusted-uris'
> about:config variable, and then it works well, too. Dunno about other
> browsers.

> (for some infathomable reason, the firefox developers consider Negotiate
> authentication to be unsafe with untrusted and/or non-SSL hosts. Dunno
> why that is, and never saw a compelling argument...)

> (for some infathomable reason, the firefox developers consider Negotiate
> authentication to be unsafe with untrusted and/or non-SSL hosts. Dunno
> why that is, and never saw a compelling argument...)