On Tue, Apr 06, 2004 at 12:05:15AM +0200, Michael Tautschnig wrote:
> On Monday, 05. April 2004 21:13, Jan Harkes wrote:
> > Nothing really. It just links Coda against libcrypto for the MD5 and
> > SHA1 digest algorithms. The main tree already has 'reference' C
> > implementations of these functions so there is no functional difference.
> > But libcrypto typically has an optimized assembly version, so using
> > those should be useful for performance reasons.
> 
> What about the passwords? How are they hashed? MD5?

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.

* http://ftp.digital.com/pub/DEC/SRC/research-reports/abstracts/src-rr-039.html

> > I might also have made the kerberos code (used as an alternative to the
> > Coda authentication) dependent on this option.
> 
> Yes, I think you did - btw is there any active development done there? I 
> submitted a small hack to the BTS as I intend to use Coda in a 
> kerberos-environment and was not able to use the current code.

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'.

The realm name is not necessarily directly related to the hostname,
krb_get_host_realm would use DNS or the local krb5.conf (or krb.realms)
file to map '.domain.name' to 'REALM.NAME'.

> Are there any plans concerning the implementation of encryption? 

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).

Jan