On Tue, Apr 06, 2004 at 10:08:23AM +0200, Michael Tautschnig wrote:
> > It is a shared secret algorithm, so the passwords in /vice/db/auth2.pw
> > are only XOR encoded because the auth2 daemon needs to be able to get at
> > the identical secret.
> >
> > If we were to hashing them it would have to be on both sides and as such
> > it wouldn't increase security at all. On the other hand, passwords are
> > never sent over the wire during the authentication handshake. We use a
> > modified Needham-Schroeder which is the variant that was described in
> > the Ban Logic paper* where a vulnerability was found in the unmodified
> > N-S handshake.
> >
> So is there anything one could use as an unmatchable substitution, because 
> kerberos renders this secret useless and I want to make sure, people are only 
> allowed to get tokens, when they do that using kerberos!

I believe that if the name is not listed in the auth2.pw file, you can
only get tokens by presenting the kerberos ticket. You can even compile
the auth2 server without Coda authentication so that it will only accept
kerberos tickets.

> > I was wondering about that patch, it doesn't seem to make sense. It
> > simply capitalizes the hostname before it is passed to the kerberos
> > canonicalization and realm functions.
> >
> > i.e. it is 'hostname', then krb_canonicalize_host should turn this into
> > 'hostname.domain.name', and finally krb_get_host_realm should turn the
> > fqdn hostname into the appropriate realm 'REALM.NAME'.
>
> Well, actually auth2 wanted a token for host/HOSTNAME.DOMAIN_at_KRB5REALM, but 
> clog supplied one for host/HOSTNAME.domain_at_KRB5REALM - this was 
> debugging-output I created in get_principal right after krb_canonicalize_host 
> - and I don't think this hostname is changed anymore!? The point might be, 
> that clog already supplied the fqdn, so krb_canonicalize_host left it 
> unchanged, wheres auth2 simply supplies NULL here!

Argh, you could be right but I don't really know enough about kerberos
to say for sure...

IVAN, HELP!!! Can the patch that is attached to Michael's bug report
break anything?

    http://www.coda.cs.cmu.edu/rt2/Ticket/Display.html?id=864

> > Nothing concrete right now. In either case, we would have to do it on
> > the RPC2 library level. The RPC2 request/response messages would have to
> > be encrypted. But the SFTP data transfers could probably be handled by
> > Coda itself (i.e. only send already encrypted files).
>
> I might use IPSec right now, but having natively encrypted data would be very 
> nice...

I've used a ppp-over-ssh tunnel quite successfully myself. And Greg
Troxel has been running Coda over IPsec for a couple of years now with
some success.

    http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2000/2143.html
    http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2002/4420.html

Jan