Common Solutions Group Authentication PPG Report September 26, 1994 "Inter-Institutional Security Infrastructure: Analysis and Proposal" Written by: Thomas Dimock Ted Hanss Jeff Hodges (Editor) Theodore Ts'o John Vollbrecht Introduction: ------------- This document is the report from the Authentication Project Planning Group of the Common Solutions Group. In it, we present a recast problem statement, various approaches, and recommendations and goals. Our recommendations address policy and security service deployment and operation more than advocating new software development activities for the first year. Instituting common systems using existing code should accomplish significant enhancements in our cooperative authentication infrastructures. Problem Statement: ------------------ Presently, there is only modest provision for interactions between the security domains of our institutions, where security has the three facets of authentication, privacy, and integrity. We need to architect an inter-institutional security infrastructure which will address the following goal and subgoals (not necessarily in priority order)... Provide the capability for secure, unambiguous, universal ("inter-realm") identification of an actor. A. Provide for secure and attributable inter-institutional "store-and-forward" interactions, e.g. the exchange of email and files. B. Provide for secure and attributable inter-institutional "real-time" interactions. E.g. enable individuals from other institutions to access real-time resources in an authenticated fashion (e.g. AFS, telnet/rlogin). Summary of Available Technologies: ---------------------------------- Presently widely deployed in an institutionally centrally-administered fashion: Kerberos V4 in various flavors (e.g. AFS's kaserver) Emerging: Kerberos V5 DCE Public Key (RSA-based) PGP Embedded in applications (AOCE, Notes, Netware, ...) Discussion: ----------- Problem A: store-and-forward interactions We feel Public-Key (PK) technology is the appropriate general solution. Example systems which use PK technology include Pretty Good Privacy (PGP) and Privacy-Enhanced Mail (PEM). PK technology may be used to ensure "privacy" and "integrity" as well as providing (digital) "signature". See [Zimmerman] for an in-depth discussion of these concepts. Example store-and-forward applications include Stanford and MIT exchanging transcripts for undergrads applying to graduate school at either place and individuals at Michigan sending email to Cornell. Privacy is ensuring that only the person you send something to, e.g. a file or a mail message, can read it. Integrity is ensuring that a message's or file's contents have not been changed, inadvertantly or otherwise. Signature assures us as to who originated the message or file. One of the primary issues in any PK-based system is how the system obtains the public key of the various users in the system. If there is a flaw in the method by which a system chooses which public key to use when trying to verify a signature, or sending an encrypted message, that system will not be secure. There are two general models which have been proposed. The first is the method used by the PEM system, and the second is the method used by the PGP system. Unfortunately, a detailed description of how these various sytems works is beyond the scope of this paper. However, we will attempt to give just a flavor of the differences between the two models. The PEM model The PEM model uses X.509 certificates, and imposes a very rigid heirarchy on the X.509 certification hierarchy. The advantages of such a hierarchy are that verifying the trustworthyness and legitmacy of a particular public key is very simple. This can be very important in commercial EDI applications. Unfortunately, the PEM model has several problems which has sigificantly slowed down (perhaps fatally) the acceptance of the PEM model. The first problem is that the PEM model concentrates a large amount of trust near the root of the hierarchy. If a particular node in the hierarchy is compromised, the attacker can forge a digital signatures for anyone underneath that point in the hierarchy. Because of this, there are fearsome liability exposures associated with running a Certification Authority (CA); and this problem is especially bad at the root. For instance, users' certificates may possibly be required to be revoked en masse if their CA does something to violate their charter. These liability issues have sparked a legal tangle of proposed legal agreements and contracts which have significantly delayed the deployment of the root and the top levels of the PEM hierarchy. The U.S. Postal Service has suggested that it may be the appropriate provider of a certification authority as it looks to recast its role in the future. Any such service, however, is still several years away. The second problem is that multiple, parallel PEM CA hierarchies being proposed and set up. These high-level CA hierarchies, called a Policy Certifying Authorities, are not yet tied together. As a result, you must make one of them your "root" and then you can interact only with others in that same PCA. Another issue with the PEM model is its use of X.500 style distinguished names. This has been a sigificant reason for its lack of acceptance within the Internet community. X.500-style distinguished names suffer from two problems. The first is that they are large and clumsy. The second is that they are incompatible with Internet email addresses. Please see Appendix 1 for a more in-depth discussion of the X.500-style distinguished names issue. Perhaps the final reason why PEM has not been adopted is that the one freely available implementation is large, cumbersome, hard to compile and install, and in general, not well done. Additionally, the free implementation is only available for Unix systems. The PGP model In contrast, the PGP model is much more free-form and general. It also uses certificates, but not X.509-format certificates. Instead of a strict hierarchy of CA's, there is a network or mesh of individuals or entities that have been "introduced" to each other. Each user of another's certificate must make their own determination as to how much they trust various "introducers" in the network. See [Zimmerman] for an in-depth discussion. While there is no formally recognized conventions and procedures to ensure trust, in practice this scheme has worked relatively well. In addition, individuals and institutions are free to layer whatever trust-assurance conventions and procedures they desire on top of the basic technology. (We will be proposing such a convention later in this report.) PGP is small and easy to install. It does not require an individual sign legal agreements before using PGP. An institution that wishes to distributed PGP, however, must sign an agreement with RSADSI. Additionally, it is freely available on a wide variety of platforms, including Unix, PC/Dos, Macintosh, VMS, Amiga, and more. We would want to investigate incorporating PGP into various applications, such as varioius email tools (e.g. Eudora, mh, pine, mailstrom, etc) in order to make it easier to use. Right now it requires you to sign files which you then inmsert into an email message. However, that brings up the issue of whether we give the application code to RSADSI or get a paid-for license. Summary Issues with the PEM model are that... Rigid CA hierarchy with unclear legal liability issues still being defined. The high-level PCAs aren't tied together yet. Dependency upon X.500 names. Low usage levels of the one Internet-available unix-only implementation. Benefits are that... Trust levels are clear. There is an infrastructure supporting explicit key revocation. Issues with the PGP approach are that... There's no formally recognized conventions and procedures to ensure trust. There's no explicit key revocation infrastructure. Need to investigate incorporating PGP into various client applications (e.g. email programs). Would need to decide on how to approach RSA's licensing requirements. Benefits are that... PGP is a "component technology" whose usage style is tailorable. PGP is in widespread use on the Internet. PGP is available for many platforms. Recommendation We recommend using PGP as the basis for inter-institutional store-and-forward interactions. Problem B. "real-time" interactions Example "real-time" applications would include a Stanford faculty member accessing (with authorization) files in a U-M faculty member's AFS home directory or a researcher at MIT running an application on the Cornell supercomputer without having to enter a new login and password. We can address this issue by exchanging Kerberos inter-realm keys between our various institutions. Presently, this is the one and only option as Kerberos is the defacto standard campus-oriented, real-time authentication technology. In doing this, we make it possible for cooperating researchers, or administrative staff, or other groups, to allow foreign users to authenticate and have access to their local resources without needing to create that foreign user a local account. Instead, all that is necessary will be to place the foreign user on the proper access control list. For example, if MIT, UMich, and Stanford were engaging in a joint development project, it might be enough to simply create a directory on one of the Universities' AFS servers, and place each of the developers from the three schools on that directory's AFS Access Control List. We note that since many applications are file-based, inter-realm AFS will likely be very useful in solving the general inter-institutional operation problem. There are some issues with the key exchange, however. The first one is the so-called "n-squared (n**2) problem of key exchange". This has to do with the fact that every site has to perform key exchange with every other site with which they wish to interact. Thus the cost of adding another institution to the "key exchange community" increases proportionally to the square of the number of sites. An additional aspect to this is being able to perform the key exchange in a secure and certifiable manner. I.e. do we know that we are indeed working with the legitimately responsible person of an institution that is joining the group? Has the key been tampered with in transit? Is it the legitimate key (even though we're dealing with the correct person)? We note, though, that we can mitigate these issues if we have a secure email infrastructure; using PGP, for example. This could support authentication of the person supplying the key (and accepting all of ours), plus authentication and integrity guarantees of the keys themselves and privacy for them in transit. The second key exchange issue is that in Kerberos V4, it is relatively easy for application writers to forget to make their programs check the realm information which is returned by Kerberos. If such buggy application programs are in use, then enabling Kerberos inter-realm authentication may expose some security holes which had not been previously visible. An example of such a problem was found in early Post Office Protocol servers deployed in Athena, which only checked the username of the ticket, and not the instance or realm portion of the Kerberos name. Unfortunately, the API of Kerberos V4 makes it relatively easy for application writers to overlook the other portions of the Kerberos name, and thus forget to check them for appropriateness. Fortunately, this deficiency is corrected in the Kerberos V5 API, since the entire Kerberos principal is returned in a single abstract data type thus lowering the odds of such bugs occuring. While most "Kerberized" applications which have been distributed on the net should not have this problem, sites who participate in key exchange may wish to examine and/or test their in-use applications to ensure correct behavior, and ensure that on-going and future in-house development activities take this into account. Requirements on the solutions: ------------------------------ 1. This work must not impede, and hopefully will enable, current work on enabling location-independent network access -- e.g. Bitnet3. See Appendix 2 for discussion and pointers to more information. 2. This work should enable the secure linkage of inter-institutional applications (e.g. for transcript exchange, for student info exchange, to support research applications, etc.) However, this type of requirement depends on the nature of the applications and the desired manner of linkage. They are specific instances of the more general case of having inter-institutional authentication and will have to be approached on a case-by-case basis once we've addressed the general case. Achievable Goals -- Summary: ---------------------------- 1. Near term (within 6 months) Execute proof-of-concept demonstration. See below. 2. Intermediate term -- by September 1995 perform: A. Provide for secure and attributable exchange of email and files. work towards having PGP key certification and distribution between institutions. B. Promote the exchange of Kerberos inter-realm keys. (Some of our institutions may already share Kerberos keys already.) C. Investigate and move towards installing AFS software which can support inter-realm authentication, and enable it. Some development work here may be required, to fold together the various aklog/cklog programs so that there can be one program that works for all sites (currently, if you want to authenticate to MIT AFS servers, you have to use aklog. If you want to do inter-realm authentication to a cell using a kaserver, you have to use cklog, etc.). D. Support location-independent network access (see Appendix 2) 3. Long term -- by September 1996 have in place: A. inter-realm authentication utilizing DCE Security? B. interoperable directory services (e.g., X.500 and DCE Directory Service)? C. cross-institutional authorization groups? Achievable Goals -- approaches and issues: ------------------------------------------ Goal A: MIT's approach to PGP CA issues is their kerberos-mediated PGP key-signing service. This service works in the following manner... The service will accept Kerberos authentications and sign a user's PGP keys. This will allow the users to generate PGP keys, and as long as they have Kerberos credentials, and the name in their PGP key matches their principle name in their Kerberos credentials, it will sign the PGP key, thus giving that key some minimal amount of trust. We recommend that each site run a similar Kerberos-mediated PGP key signing server. (Source code will be available from MIT). Each site's PGP key signing server will have its own public/private key pair, and at least initially each site will cross-certify each other's PGP key signing keys. Later on, we can look into setting up a higher-level certifying authority, possibly run under the auspices of Educom --- but that's something which doesn't need to be considered until after the initial phase of deployment. Goal B: We need to carefully investigate the ramifications to existing services and applications before widely using, as noted in the discussion above. The inter-realm key exchange should ideally leverage off of the work produced to satisfy Goal A. This is needed in order to ensure that the exchanges occur in a secure, attributable fashion without requiring face-to-face meetings of the Kerberos administrators (The old method of exchanging keys on the back of fortune cookie messages after eating lunch or dinner at a chinese restaurant works, but it requires a travel budget). Goal A - detailed issues: We can forsee, though, that even in the academic institution world, there will likely be needs for differing trust levels and assurances. For example, transcripts might require a less (or at least different) trust level than the exchange of financial information. And loose collaboration between researchers might be yet different. Another set of issues are the ones revolving around client tools (e.g. email user agents) and their user interfaces and how well they incorporate and utilize PK concepts. For example, the information presented to the user as to who signed a given secure message must be presented out-of-band (e.g. in a separate dialog box) because it can otherwise be "faked out" by including the appropriate text in the original message. Additionally, we note that this assumes that the client user interface is relatively secure. Dialog boxes can be faked up as well---though that's more difficult to do that faking the look of a signed message. Another example is how to handle supposedly "secure" messages that are originated outside of the user's trust domain. The user should receive some sort of notification on this. PGP is just now gaining steam. Not many free/shareware apps yet incorporate it, much less address the raft of UI issues. This will need to be addressed in the context of making it a useful underlying technology for our common users. We'll have different PK certification schemes on our campuses due to PK (typically RSA-based) being incorporated into various off-the-shelf products (e.g. lotus notes, MacOS Pro (aoce), etc.). How can we make it as seamless as possible for the individual end user? do we need to? Goal B - detailed issues: There are additional issues in that AFS's kaserver may not support inter-realm authentication (depending upon version of AFS in use). Thus institutions may have to upgrade or patch their AFS code in order to participate (and additionally modify various client tools such as "klog"). The inter-realm functionality is alegedly operational in recent 3.3 releases, and Transarc does _not_ support it. However, CMU depends heavily on inter-realm AFS continuing to work, and Transarc seems well-disposed to at least not break it in future releases. See Appendix 3. Not many vendor-supplied apps speak Kerberos today. There is a lack of a Kerberos standard API for PC and Macintosh environments. Differing security infrastructures among our institutions -- there's considerable inertia here since we all have non-trivial, operational infrastructures: MIT is currently using Kerberos V4 servers, with a V5 server as a slave server. They will soon be transitioning to running a V5 server as the master server. The V5 servers will support V4 requests as a backwards compatibility measure, and they anticiate that they will have to keep the backwards compatibility support in place for a relatively long time. Stanford is running Transarc's AFS 3.3 (krb v4) kaserver, as is UMich. Note that UMich is looking at how to best support KerbIV, KerbV, and DCE security services in a single cell/realm. OS environment issues: (example - user interface issue) if I go poke around in /afs/umich.edu directories with "ls -l", and there are files tagged with UIDs that happen to match UIDs in my local password file, then the files are falsely displayed as belonging to those local users. Will DFS have this same issue? (yes). It will cause some level of background noise among the user community. Ultimately, it should be addressed by the operating system vendors modifying their client tools (ls, tar, etc.) to use a different lookup on file ownership. There are probably other such examples of where various facets of the OS environment, and perhaps also the application environment, won't behave with strictly correct semantics in the inter-realm case. UMich uses the "uniqname" service to hand out unique kerberos principles -- i.e. it's a tool for establishing a common name space across the whole campus. Where it might be relevant for inter-realm is in reserving names we need to or desire to keep unique across institutions (e.g., registrar@school.edu as the process that exchanges transcripts). This would be covered by "cross-institutional authorization groups" listed under long term goals. Proof-of-concept demonstration: ------------------------------- First, perform inter-realm key exchange "by hand" between some of our institutions and test functionality, e.g. by manipulating files in each other's AFS filing hierarchy. Next, deploy experimental kerberos-mediated PGP key-signing services, cross-certifying each other's PGP key signing keys. Then exchange signed & sealed email between individuals at separate institutions. Overall Issues: --------------- (in no particular order) Authorization: There's presently no real standards for a common authorization service, tho DCE has explicit provisions. Its probably not an issue for a particular authorization service implementation to be common among the institutions because it probably wouldn't be contacted directly by clients, but rather by the services the clients are trying to access. Secure local login: UMich is looking at using Security Dynamic's SecurID cards, though they are not yet integrated with Kerberos (they are waiting for the vendor to complete that work). Stanford is using S/Key ad-hoc internally, as is MIT. MIT has discussed having the S/Key response-to-challenge algoritm put on a card, although it's not something that they are currently actively pursuing. Technology Maturity & penetration: DCE continues to evolve. DCE 1.1 and 1.2 will have various features which will help facilitate cooperative inter-realm authentication. Some of these are easily moving principals from one cell to another, delegation, multi-crypto support (to negotiate among difference available crypto systems), public key-based authentication, multi-cell groups, etc. Architecting, deploying, and managing internal and inter-realm security domains could be aided by ubiquitous, multi-vendor DCE support. Vendors cooperation and buy-in: We believe we need to lobby the vendors, providing them with white papers, security requirements, etc. in order to encourage them to put more emphasis and resources on cooperatively addressing global security issues. We believe that collectively we (end users) can make a difference, especially as the commercial end users are getting better educated about these issues. For example, we are getting RSA-derived services from Apple AOCE, Lotus Notes, Novell Netware, etc. However, these systems enforce varying levels of security and aren't interoperable. Some specific examples (courtesy Ted Hanss)... 1. We need a single login to client workstations (which will encompass our own applications along with environments from Banyan, Novell, Apple, Microsoft, etc.). This has to be done without lowering the overall security environment. For example, I'm not a fan of Apple's AOCE keychain approach to single login. In our work on Netware to DCE integration we intend to provide Kerberos tickets for Netware file service and not "batch" together the two logins just behind a modified client login program. 2. We need a way to raise the security levels of individual hosts. For example, putting a public key-enabled email package on a Mac when the user interface isn't secure just invites spoofed alerts being presented to the user. (E.g., the Mac hack done last year that presented users with an alert OK'ing each AOCE digital signature regardless of whether or not it was authentic.) References ---------- [Zimmerman] PGP documentation. Available at... http://www.pegasus.esprit.ec.org/people/arne/pgp.html Appendicies ----------- Appendix 1: Issues with X.500 style distinguished names. X.500-style distinguished names suffer from two problems. The first is that they are clumsy. An example X.500 style distinguished name might be: /C=United States of America/SP=Massachusetts/OU=Massachusetts Institute of Technology/OU=MIT Artificial Intelligence Laboratory/CN=Richard Stallman In contrast, the equivalent DNS/Internet style rendition of the same name would be: "rms@ai.mit.edu". While the X.500-style name is much more understandable and readable, it is much harder to type in, and it doesn't fit very well on a business card. Proponents of X.500-style names argue that users are never supposed to type in an X.500 name --- instead, they are supposed to get them from X.500 directories. Unfortunately, very few sites actually have X.500 directories installed, and many of the sites that do have X.500 directories running are doing so only on an experimental basis, and may not have all of their users registered with the server. (However, we note that it is certainly possible to deploy a production X.500 server since UMich has done so based on the ISODE distribution. All campus faculty, staff, and students are registered within it (almost 100,000 individuals). It runs under high load, handling approximately 300,000 transactions/day.) Even if the X.500 servers were widely deployed, however, the dependency on the X.500 protocol adds a sigificant amount of complexity to user agents that try to support PEM. In particular, the user interface requirements are much more demanding; a GUI is almost an entry-level requirement, so that the user can point and click on the appropriate distriguished name after the application has contacted the X.500 server and performed an X.500 query. And, of course, systems that do not have direct access to the Internet will not be able to access the X.500 servers. The second problem with the X.500-style names is that they are incompatible with Internet email addresses. That is, there is no way to programatically transform "rms@gnu.ai.mit.edu" to: /C=United States of America/SP=Massachusetts/OU=Massachusetts Institute of Technology/OU=MIT Artificial Intelligence Laboratory/CN=Richard Stallman This "impedence mismatch" introduces additional complexity into a prospective PEM client, and additional opportunities for security breaches, since the client must keep a secure mapping between the complex X.500 names and the standard Internet email addresses. Note that these issues are ones which arise out of how PEM (or any other similar application, such as X.400 mail) depends upon X.500 Distinguished Names. This does not necessarily indicate that we cannot usefully utilize the X.500 directory service as a part of our overall distributed infrastructure --- merely that we may not want to use the X.500 as part of how we name individuals. Appendix 2: location-independent network access If we can obtain full network access, when on the road for example, then it is usually a fairly simple matter to authenticate directly to our home institution and utilize both real-time and store-and-forward resources. Bitnet3, sponsored by CREN, is work-in-progress towards this goal. See... ftp://merit.edu/pub/michnet/dist.auth.arc.0394.ps ..for an architectural overview. Cornell, Prinction, the CREN office in DC, and UMich are all working together on this, and are currently experimenting in a test mode. Cornell will be doing some of the billing & accounting, but it is still being designed and developed. Sometimes people who are visiting and working temporarily at another institution need to utilize that institution's workstation(s) for network (and home institution) access. Having procedures and technology that enable the generation of temporary IDs/accounts for this situation is desirable. UMich's Uniqname system is an example of a solution. More information about it can be found at... /afs/umich.edu/group/itd/ftp/sysadm/uniqname/uniq.lisa.paper.ps.Z Another approach to this might be, given an inter-realm authentication would be for the host institution to enable one to log onto given workstations utilizing their foreign (i.e. home) ID -- that is, they qualify it with their home realm. Then they may access their home institution resources with their usual privileges. Issues: MIT is planning on deploying Xyplex terminal servers to address this issue - they have raw Kerberos support built in. Thus there is skew among our institutions on solutions. Appendix 3: inter-realm auth and AFS Hdate: Wed, 21 Sep 1994 13:24:48 +0500 HFrom: Theodore Ts'o HTo: authppg@list.Stanford.EDU Hin-reply-to: Jeff Hodges's message of Fri, 16 Sep 94 14:17:56 -0700, Hsubject: Re: Revamped authppg report skeleton #3 OK. I've talked to our internal AFS experts as well as talking to Wally from CMU. Here's the story as I understand it. * Transarc does _not_ support the interrealm AFS code; however they have merged in the changes from CMU, and there does seem to be interest within Transarc not to break what's already there. * While there were bugs (byte-order problems) in 3.2 and early 3.3 versions, these are supposedly fixed in recent 3.3 releases from Transarc. Wally believes that the stuff from Transarc should just work. * Transarc does not provide any clients, though. You have to pick up a new utility "cklog", found in: /afs/grand.central.org/pub/afs-contrib/tools/cklog if you are using a kaserver, or you have to get a copy of MIT's aklog if you want to authenticate using a traditional Kerberos server. * Activating the the interrealm support does not give foreign users access to directories restricted to system:authuser --- instead, they are automatically placed into the magic group system:authuser@KERBEROS.REALM.