(Illustration by Gaich Muramatsu)
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/Received on 1998-03-31 11:13:04