|
|
|
The DICE architecture grew out of discussions amongst the original DICE project group (Paul Anderson, Jeremy Olsen, Alastair Scobie, Simon Wilkinson, with Tim Colles, Lex Holt and George Ross joining us along the way). It was refined over a number of meetings in early 2000, and continued to develop through 2001.
The DICE environment has a number of clearly established development goals. These goals are an expanded version of those presented in Paul Anderson and Alastair Scobies's original proposal for DICE.
These maybe management buzzwords but they are vitally important to the success of the DICE system. A state of the art configuration management system is required to keep machine configurations in step, and to make the process of initially configuring, and updating, machines as rapid and simple as possible. Reducing the duplication of user and system data, so that there is one authoritative source for every data item, will greatly simplify other management tasks.
The support of laptops is increasingly important. These laptops can be located on our networks, on dialup links through other ISPs, on conference provided networks, on wireless links, or even not network connected at all.
The same computing experience should be available to the user whilst connected, regardless of their network location, and without them having to undertake large quantities of manual reconfiguration. Disconnected machines should have as rich a functionality as is possible, and should recover when next connected.
There is an increasing tendency for more people than just systems staff to manage machines. We want to be able to allow this, without reducing the security of the rest of the machines. In particular, the configuration and security systems should support multiple realms of trust within our network, rather than the current model which has only one. The configuration system needs to be able to allow different users to change different pieces of configuration information, whilst ensuring the stability of both the machine and the network.
We want to develop a more flexible security model. Currently security is based on host-based trust. This isn't tenable in the world outlined by the three previous goals, and is fairly unworkable even now. A model which relies on user-based trust mechanisms, falling back to host-based trust where appropriate will be far more flexible. In addition, any trust relationships must be securely established, without relying upon the security of the network layer.
The architecture which has been developed to meet these goals is still, in many areas, a work in progress. It was decided fairly early that we would concentrate our efforts on a number of key areas. The following are those which have been developed for the stage 1 rollout.
In addition, we plan on investigating other areas in the stage 2 work, which should begin after the successful completion of the summer rollout. No more will be said about these here.
DICE requires a security model which allows both user and host based trust. For the majority of actions which are undertaken by, or on behalf of, a user, that user's identity is used to authenticate them to the network service they require. That network service is also authenticated back to the user.
Some actions, however, are not initiated by a user. Items such as directory service replication, software updates and the like have to be performed using a trust relationship based on the host's, rather than the user's identity.
All of these relationships must be established in a secure fashion. In particular, our mobility goals mean that we can make no guarantees as to the security of the network layer. This means that any authentication schemes which use IP address, or DNS name, as a means of trust should not be used within the DICE world.
The central authentication system for DICE is Kerberos. We use both user, and host, kerberos keys in order to establish both types of trust relationship. Local additions are used to allow Kerberos (a network based scheme) passwords to also be used for disconnected authentication on the local machine. Limitations of other protocols mean that in some cases X509 public key certifications may also be used. However, the management of these certificates is completely governed by the underlying Kerberos system.
Our security model is that all cross-network communications, which are not undertaken anonymously, should be secured using one of the above methods. For all protocols other than HTTP the use of native Kerberos (or one of API wrappers supporting it such as GSSAPI or SASL) is preferred. For HTTP, the use of TLS with X509 certificates is recommended.
We have not taken any view on whether encryption (as opposed to authentication) should be used.
The DICE authorisation scheme will be a role and capability based system. Users will have both primary and secondary roles, with the primary information being collected from the HR information in the divisional database. User roles, and the mapping of those roles to individual capabilities will be maintained within the LDAP service. A netgroup style interface will be provided for use by legacy applications.
DICE is based around a number of directory services, each of them filling a different role. The proposal for first stage deployment is that the following directories will be provided:
The data stored in each of these directories can be summarised as follows:
In addition to these directories, there also exist a number of "flat files" which are used to configure various devices, such as network switches, DHCP servers and the like. It is likely that these will eventually disappear into a Network Directory Service of some kind, which will hold all of the network information, feeding the DNS server as appropriate.
The intention is that all user related data for systems use will reside either within the KDC or the LDAP server. The use of flat files for maintaining user information will be discouraged and deprecated.
The architectural intention is that all machine spanning information, such as filesystem maps, printer maps, and the like, be stored within the LDAP repository. It is likely that in later stages the roles of the KDC and the LDAP repository will become more tightly coupled, and it is possible that some LCFG information will move into the LDAP repository as well.
The LDAP system is implemented with a single master directory server for the Informatics domain. Implementation details require that this directory service have an replica on every DICE machine. This solves both the disconnected use problem, and provides C library name service switch level access to the directory data via a trusted path.
NIS is replaced by using the C libraries name service switch to direct requests for all maps, except host information, to the LDAP server. Host information requests go directly to the DNS server, also replicated on every machine.
Access to the LDAP server is available anonymously (for read access to certain data) and via Kerberos authenticated connections. It seems increasingly likely that we will also provide X509 certificates for core LDAP services, to allow SSL based anonymous access (where the server must authenticate to the client).
In future years, we intend that DICE will look at a number of other areas, in addition to refining the core infrastructure outlined above
At the moment we have two directories carrying user information (LDAP and the KDC) and three directories maintaining local only information (LDAP, the KDC and LCFG). It is likely that user management information currently held within the KDC will be moved into the LDAP data store. Following this, providing the security aspects can be resolved, it would make sense to also move the key material from the KDC, merging the roles of the LDAP directory and the KDC.
LCFG currently uses a HTTP based directory, allowing low granularity access to data. It is conceptually possible that this information could also be migrated into a LDAP datastore, providing common transport for all local directory information, removing the problems of securing the HTTP datalink, and allowing finer granularity access to configuration information. However, this would greatly increase the size of the directory, and concerns about replication issues would have to be resolved first.
The current Achilles heel of the DICE system as discussed above is our filesystem. Time has not allowed a consideration of alternatives to NFSv3, as used across the Division currently, and the stage 1 deployment will continue to use NFS. Our use of NFS provides for little or no security, beyond the IP-based trust model. This makes it hard to say anything about the overall security of the rest of the system, given the dependence that a number of components place on home directories retrieved over the network.
In addition, it makes our mobility, disconnected operation, and distributed management goals harder to fulfill. We cannot provide filesystem access to machines outside our managed networks, we need to restrict access to those machines where the 'root' user is fully trusted, and only userland tools such as 'unison' can deal with the disconnected aspects. Therefore one of the key elements for future study is alternative network file systems.
The simple option is NFSv3 (or v4) with GSSAPI/Kerberos support; other alternatives are advanced filesystems such as AFS or Coda. This area still requires a substantial amount of investigation.
|
Please contact us with any
comments or corrections.
Unless explicitly stated otherwise, all material is copyright The University of Edinburgh |
|
