Re: [9fans] Multi-domain authentication?

[Nathaniel W Filardo <nwf@cs.jhu.edu>]

[-- Attachment #1: Type: text/plain, Size: 4177 bytes --]

On Mon, Oct 20, 2008 at 07:43:39PM -0400, erik quanstrom wrote:
> > http://osdir.com/ml/os.plan9.nine-grid/2005-06/msg00001.html is a proposal
> > from some years ago from TIP9UG to do multi-domain authentication in a way
> > somewhat reminiscent of Kerberos.[1]
> > 
> > The only change to factotum, AFAICT, was the following addition:
> >>    if(_strfindattr(s->key->attr, "grid")){
> >>      snprint(s->t.suid, sizeof s->t.suid, "%s@%s", s->t.cuid, _strfindattr(s->key->attr, "dom"));
> >>      safecpy(s->t.cuid, s->t.suid, sizeof s->t.cuid);
> >>      flog("grid user: %s", s->t.suid);
> >>    }
> > in the SHaveAuth case of p9skread.
> > 
> > This seems like a good way to go about MDA, so I am curious why this change
> > didn't get put back into the mainline code?  Is there something
> > fundamentally wrong?  Was a different approach selected?  Was the issue
> > simply tabled?
> 
> could you explain what you mean by multi-domain authentication?
> 
> i authenticate from one plan 9 authentication domain to another
> every day.  the only thing that needs to be set up is that the hostowner
> of the other auth domain's auth server needs to be in your /lib/ndb/auth.
> (this is already done if you use bootes.)  and you need a line with
> auth and authdom keys added to /lib/ndb/local on the auth client's
> machine.

Here you are merely authenticating as a user in the remote domain; that you
exist in the local domain is immaterial to the remote domain.  The TIP9UG
proposal above allows a domains to delegate part of its user namespace to
another, by appending @delegatee to the usernames of all users logging in
via credentials authenticated from the delegatee auth server.

> is there something else you are looking for?

Yes, something more like Kerberos.  The question then becomes why... I want
AFS (specifically PTS) style semantics for distributed resources, where I
can create groups without having to pester my administrator and users from
remote systems exist as local entities and can be included in groups as
such.
 
> > [1] I say similar to Kerberos in that it requires a domain A wishing to
> > accept identities from domain B to have a key from B's authsrv.  
> 
> i don't understand this.  which key are you talking about?
 
I mean: This delegation is done by having the delegatee give the delegator a
user account and the delegator having their perimeter machines' hostowners'
factotums use that key in addition to their delegator-domain key.

Being a little more concrete, suppose dom=example.com wants to allow
dom=bell-labs.com users to be referred to as "...@bell-labs.com".  Each domain's
perimeter machines (e.g. CPU servers) are already given keys with speaksfor
privileges against their local domain.

To enable the cross-domain authentication,
  0. bell-labs.com creates a key (user) for example.com, perhaps named 
     "mda-example.com" and send the password to the example.com
     administrator.

  1. The example.com administrator ... 

     1.0. ensures that bell-labs.com has the correct record in
          /lib/ndb/local

     1.1. installs this key into their perimeter machines, which are running
          the TIP9UG factotum patch above.

     1.2. The example.com administrator gives this key speaksfor= privileges
          for "*@bell-labs.com"

  2. The bell-labs.com administrator ensures that /lib/ndb/local says to use
     the bell-labs.com authentication server, not the example.com one, when
     talking to example.com.

  3. It is now possible for any bell-labs.com user to log in to the
     example.com domain without having asked example.com for a user account.
     Further, all example.com servers see the user as "...@bell-labs.com"
     and are not confused about who filled up the WORM.

This is very similar to Kerberos's key exchange mechanism for cross-domain
validation, except that AFAIK in Kerberos the KDCs are a little more in on
the joke, whereas here that is not necessary.  Contrawise, here, all
perimeter machines need to have the delegatee key in their factotums'
keyrings.

Does that make sense?
--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]