On Wednesday, 21. April 2004 12:03, Ivan Popov wrote:
> 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?
Either _any_ kdc both client and server can connect to, or the auth2-server 
sends a list of proposals.

> If you mean that the existing tgts have to point out Kerberos realms for
> Coda realms, how do they do it?
Sorry, I was wrong here - but it might be possible to maintain some 
config-option listing the possible kerberos-realms.

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

Well - I think one point needs to be discussed here: What do we accept to be 
configured "statically" in the config-files:
- krb5-realm (default for server & client)
- client: possible krb5-realms (as realms<->kdcs are configured in krb5.conf)
- server: acceptable krb5-realms (because they are in the keytab)

> 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?..
I can only see 2 possible solutions: Either maintain a list (on the server) of 
possible principals and deliver it to the client, who in turn then chooses 
one/tries all of them; or add some "-p" option to clog to enter the desired 
principal - so: Should knowledge about the principals kept on the client- or 
server-side?

>
> :) 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.
This is implemented yet.

>  - 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
But who cares for the mapping string<->coda-number? Is it the users 
responsibility to do `clog as <USERNAME>`? What happens, if <USERNAME> is 
omitted, is the users numeric id taken for the mapping or the name? This is 
something I have not yet understood concerning the current implementation...

>  - the identity name strings can be formed as
>      <authority-dependent-name>/<authority-name-chosen-by-the-coda-realm>
This is really nice, but there must be some default for all that - users _are_ 
lazy, they do want some kind of plug & play... This is the reason for all of 
my talking - _how to determine the default_ ? People probably don't know 
where they got (to stick to the example) their kerberos-tgt from, may it be 
andrew.cmu.edu or cs.cmu.edu - doing more behind the scenes might help a lot, 
although it should still be possible to specify that exactly on demand (i.e. 
on the command-line).

>    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"
But how to do that, e.g. should the kerberos-realm be explicitly specified or 
possible values be discussed behind the scenes? Or should one simply use the 
defaults provided by the service-specific config-files?
 
> 3. possibly talk some other protocol(s) to fetch the resulting Coda 
> token "rpc2 to send a Kerberos ticket and get a Coda token"
Of what importance is that here? Might there be any problems if you used one 
or the other? Isn't that only implementation-specific or are there 
dependencies?

>    4. locate the corresponding resources
>       "which host and port that rpc2 daemon is running on"
But that's only of importance on the server side, or have I understood 
something completely wrong?
What about using nsswitch on the auth2-server-side? This would provide a 
generic interface for user-management (and you are still independet of any 
existing passwd etc. (I would love to have an entry like "coda: files 
ldap"...) 

>  - 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.
Nice!

> 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.
But how to get to appropriate defaults? 

> 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.
But how can a coda-client/server get information, e.g. wheter it is using ssl 
or not (even worse: ipsec...)

> 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.
A great idea - but somehow some kind of plug & play needs to be realizeable. 
How may one get the correct config - would it be possible to get all that 
from e.g. the DNS? (coda realm seems to be the problem, the matching servers, 
of course, are a lot easier to fetch...)

Regards, Michael