On Tue, 31 Mar 1998 braam_at_cs.cmu.edu wrote:

> I started thinking about this again.  Could we rely on kerberos for
> security -- i.e. if the portmapper is started with "-k" it can prove
> it's identity to the client. Without that it is trusted by clients? 
> 
> I assume it has nothing to hide? 
> 
> About re-registration: I like the idea of just keeping an open
> connection to the portmapper and pinging (why not "binding"?) every
> minute or so. 
> 
> This is actually a rather nice thing to have, perhaps we should build
> it.  Perhaps we should also register the portmapper with IANA
> rightaway. 

My further thoughts on the issue --

1. Security -- we may be able to farm out GetKeys to the services on the
local machine that require port-mapping service.  When they register, they
allow us to bind to *them* (perhaps providing a dynamically generated key
for us to use in binding).  We can then call portmap_ping() to see if they
are alive (variable timeout would be useful here also, btw).  Similarly,
when we need to authenticate a client, we call portmap_getkeys() to
forward the authentication.  However, before we can do that, we need to
know who to send the authentication to, and that early in the bind we have
only the subsystem.  So perhaps what we do is use the subsystem on the
portmapper to identify which service the client is looking for.  E.g., 


Client                Portmapper                  Daemon
                            <----------------------->
                            Bind + inits

                            <------------------------
                            portmap_register_port(subsys, key, name)
                            ------------------------>
                            PORTMAP_OK
                   
                            <----------------------->
                            Bind + inits (using key)


  --------------------->    ------------------------>
  Bind, subsysid of         portmap_getkey(cident)
  coda                      <------------------------
                            keys
  <---------------------
  Port information


However, this would require that the daemons provide sensitive key
information to the portmapper.  A modification would be to transfer the
entire init1 packet from the portmapper to the daemon for decrypting, and
then just have the daemon send back the session key information.  (The
actual process may vary -- I need to review my Init packets to see what
information is needed when).  This allows us to secure the portmap process
using the daemon's own authentication code.

Once in a while, the portmapper would call portmap_ping() to check to see
if a daemon was not there.  When a daemon was voluntarily giving up its
registration, it would call portmap_unmap().  For security reasons, the
portmapper might only accept registrations *from* the port that it is
registering (this is not a problem in RPC2).

One other issue is that of authentication/authorization of the
portmap_register() requests.  One restriction might be to only allow local
registrations.  Another might be to require priveledge port use to
register, or that the portmapper be preconfigured with a key.  On the
other hand, for a closed server, this is probably not a big problem, as we
trust local daemons.  I welcome suggestions in this area.

For the RPC2 portmapper, I would recommend a <1024 port, although
depending on our security model, maybe this is not required?  The bind in
RPC2 is quite powerful in this sense.

The connection back from the portmapper to the server would be a little
bit like the callbacks used between venus/vice.


  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/