What we have is a vast set of things which can be used by users. From a broader perspective what we want to achieve is that we want to name these things so that users can refer to them when they want to use any of these things. But as soon as we assign names to things, we need a naming service which can map back the names to those objects. And correct working and availability of this service is the basic requirement so that people can use these things. Hence, security comes into picture. So, we can say that naming and security are almost intertwined. Naming will not work without being secure in some sense.
Security itself involves three basic criteria:
To quote a line from the paper .Decentralizing a Global Naming Service.: A naming service is secure if it ensures that:
One thing which is missing in this list is availability, and that may be because the authors of the paper employed caching which inherently provides availability to a great extent. However, we can still add this important requirement to the list: Fourth one, Availability. Availability means the system should be available to serve the request at all times. There is one more requirement which can be assumed a part of availability itself but still I would like to highlight it separately, that is, Fifth one, Performance In a typical system where people are using naming service a lot, if a naming service is available but if performing poorly, it will render itself of no use. This, in effect, causes loss of availability.
On the other hand availability, to a great extent, derives from the structure of the naming. As written in the paper .Designing a global name service., hierarchy is the fundamental method for accommodating growth and isolating faults.
To illustrate on this point more, consider a flat hierarchy naming system. Such a system would require a single/central name server to map all the names to object. A central server becomes a single point of failure, a security risk. As if the name server is down, the whole system will come to a halt. To counter argument, we can say that we can have multiple copies of central name server running. But in that scenario, syncing of the data will consume lot of time making the system less scalable and eventually unusable. Also, server updates would require all the authentications to happen at the server end which is again not a scalable option.
Hierarchy solves such problems to great extent. If the structure of the naming supports hierarchy, then sub-sections can be made inside the whole namespace.
Name systems presented in papers such as:
Another important technique is caching which is used by almost all the naming systems mentioned. Caching involves caching of records by the clients once they have resolved a particular .name to object. mapping. Caching gives a big boost to overall availability of the service by reducing the time for repeated queries. All the naming system mentioned above use caching in one form or the other.
A good example of caching acting as a security measure would be: In case of DNS, caching at the local DNS servers takes away the motivation to DOS the root servers. Even if the root servers are DOSed for a particular time interval, very little number of users will get affected because the local DNS servers have already cached the entries and they need not go to root servers to do name resolution.
One security risk which I felt with Grapevine was the replication of the authenticator. We need to securely transfer the authenticator. Apart from that, if some permission for a user has been revoked at one registration server and before replicating it died, then still that user will be able to get authenticated using some other authenticator. "Decentralizing the global naming service" paper assumes that the server caches an unforgeable capability which expires after certain time. This paper acknowledges that it is tedious in terms of performance and client/server will have to, once in a while, contact security authority to verify that the server is (still) authorized to respond to client.s request. In Tilde Naming System, design relies on inheritance mechanism, this paper has recognized that Trusted software can be spoofed which is again a case of server being spoofed.
To sum it up, I would say that naming and security are inseparable. All the naming systems mentioned in the reading are not fully secure because they chose performance over security while designing certain aspects of the systems.