On Tue, 31 Mar 1998 thoth_at_purplefrog.com wrote:

> >  > 1) Security -- how can we secure the portmapper?  Clearly security is an
> >  > issue -- we need to know that the returned port information is correct.
> >  > However, the portmapper might be mapping the authentication service;
> >  > similarly, the portmapper might be a more general function for many
> >  > possible daemons, in which case how does it authenticate?
> 
>   NTP uses shared secrets.  SSL uses certificate authorities.  Maintaining a
> single CA certificate to verify server certificates is a little easier than
> copying all the keys around.

Bob,

I am wary about adding any PK support to part any of Coda at this point
without going into a full-out design of a PK authentication system for
Coda in general.  While it is certainly more scalable, PK still suffers
from a lot of problems -- more in the case of end-user authentication than
shared secret.  Also, I'm reluctant to create yet-another-PK-certificate
system for Coda, but am not sure the other systems out there are developed
enough at this point to use one or another.  Incorporating PK into the
RPC2 bind will require some low-level changes to the protocol.  Peter and
I are in the process of documenting and redesigning certain parts of RPC2,
so I will put a first look at PK (probably through ISA-KMP/Oakley) going
into the Bind stage.  Even adding Kerberos support requires a lot of
reconsideration of our authorization and authentication models.

As was suggested in a later email, SPKI is certainly a possibility -- what
I'd really like to see is a standard interface to the variety of
certificate systems out there so that we can plug in arbitrary PK systems
as we need to, be it SPKI, X.whatever, or DNSsec.  They each have their
advantages (be it scalability, distributed or centralized management,
etc), but I don't want to commit to one :).  Also, a reasonable policy
mechanism for mapping the different authentication systems into VIDs is
needed.  The ability to specify rules such as:

KerberosIV: Map *@CS.CMU.EDU -> * (Coda ID)
KerberosIV: Map *@ANDREW.CMU.EDU -> * (Coda ID)
KerberosV: Map */coda_at_ATHENA.MIT.EDU -> * (Coda ID)
KerberosIV: Map robert_at_WATSON.ORG -> robert (Coda ID)

is something we are about to start work on.  Each time we add a new
authentication system, we will face more of these kinds of arrangements
and requirements for mapping identities.  Especially in environments where
many different authentication systems coexist (somewhat peacefully).  One
thing I'd definitely like to see is s/Key support for administrative
accounts -- it's not clear how we integrate this into the existing Bind.
On the other hand, GSS-API/SASL do not offer us the shared-secret behavior
that is so nice about the current Bind (i.e., if I send you the packet,
it's not useful unless you can talk to some kind of auth server).

  Robert N Watson 

Carnegie Mellon University http://www.cmu.edu/
SafePort Network Services  http://www.safeport.com/
robert@fledge.watson.org   http://www.watson.org/~robert/