Hello Michael,

> In either case, it seems all not too complicated:

:)

> Let the coda-principal, allowing users to acces servers in a specified 
> CODA.REALM, be coda/<CODA.REALM>. Thus a user would be able to log into a 
> coda realm/cell if he had a valid kerberos TGT and coda/<CODA.REALM> existed 
> in the kdc's database and in the coda-server's keytab. This, of course, means 

Hmm, I get a lot of questions at once :)
Like: in _which_ kdc? How does the client figure out which Kerberos
realm and kdc it is going to use?
If you mean that the existing tgts have to point out Kerberos realms for 
Coda realms, how do they do it?
First of all I would have hard time fetching a tgt as
1. the client host kerberos libs not necessarily do DNS SRV lookup
   to locate kdcs for a Kerberos realm
2. the corresponding Kerberos realm can lack those DNS records
3. the client host admin does not bother changing krb5.conf to include
   all the information kinit needs to acquire a tgt from my Kerberos realms
   (same for the clog program trying to use a tgt)

Then imagine that a Kerberos realm administrator explicitely prohibits
any principal names which are not host/<fqdn> or <unix-account>. Period. :)
Then it would render that Kerberos user database unusable for my Coda realm?..
:) Ok, just kidding.

I think it is time to explain what we can do if we do it "right"
instead of looking for special-case solutions like existing Kerberos
related code.

We talked with Jan about a general mapping between authenticated entities
(their names differ depending on the authentication type and authentication
authority) to Coda realm uids.
We discussed a possible naming scheme which allows for any kind and any number
of authentication databases to be used for a Coda realm.

It looks as follows:

 - Logically all identities (authenticated entities) are strings.
   An identity is often connected to a physical person,
   though not necessarily - but in any case it has certain qualifications.
   Those qualifications (like the fact if it is a physical person or not,
   in case of a person - its social status and relation to the resources
   [like student, professor, helpdesk member, guest] and so on)
   are _the_ ground for all subsequent explicit decisions about the rights
   of that entity. The decisions are expressed in terms of groups and acls.

 - internal representation of an identity in Coda servers does not have
   to be a string, it can be a number instead, but it is the internal
   business of the implementation, nothing else

 - the identity name strings can be formed as
     <authority-dependent-name>/<authority-name-chosen-by-the-coda-realm>

   like
     pin/default    or    ipop/medic
   which in case of my Coda realm could mean
     "account ''pin'' authenticated via the Chalmers DCE cell"
     "account ''ipop'' authenticated via Medic Computer Group NIS server"

 - to authenticate oneself as some identity, one has to be able to
   1. talk the protocol, which the corresponding authority accepts
      "kerberos 5 to DCE cell"
      "UNIX password in plain text to a host which verifies it against NIS"
   2. locate the corresponding services
      "kdc of the DCE cell and if it is run on the standard port"
      "the host which accepts passwords over tcp connection and the port number"
   3. possibly talk some other protocol(s) to fetch the resulting Coda token
      "rpc2 to send a Kerberos ticket and get a Coda token"
   4. locate the corresponding resources
      "which host and port that rpc2 daemon is running on"

 - so a Coda realm should advertise
   which protocols and resources relate to a certain authority name
   so that an agnostic client host can do the right thing
   given a Coda realm name and a string <name>/<authority>
   to be used in that Coda realm context.

That advertisement is implemented as a very simple plain text
tcp service, compliant with the existing Coda realm resource discovery
via DNS or "realms".

The experimental clog is talking to that service of a Coda realm
and using the information for proper authentication. The result is
that we can use many different authentication methods and databases,
even simultaneously for the same Coda realm.

Of course, as a user you can set all authentication parameters manually,
if you know them, but you do not have to.
All you need is the name/authority string,
given to you by the Coda realm administrator.

A limitation of that simple scheme is that _mutual_ authentication has
to be present in all authentication methods. No "password over tcp to NIS",
as it can be trivially subverted via a forged advertisement.
But you _could_ use "plain passwords against NIS over SSL with server check",
it would be as good as UNIX hash passwords in general are - not better,
not worse. A forged advertisement would make your authentication fail
but not reveal the password to the attacker.

All implemented authentication methods imply mutual authentication.

As a side effect of this generalisation we do not any longer depend on
the Kerberos or other services' shortcomings in resource discovery.
No more client-side config files, all necessary resources are pointed out
by the Coda realm, where they belong.

Best regards,
--
Ivan