[...]
> > 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.
>
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 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!

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

> > 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).
I might use IPSec right now, but having natively encrypted data would be very 
nice...

Regards,
Michael