(A white paper for the FERC, "How to Build RINs" workshops. Version 1.0.)
William E. Johnston
The U. S. Federal Energy Regulatory Commission, in a Notice of Proposed Rulemaking ("NOPRA") (Docket No. RM95-8-000, March 29, 1995) has proposed a set of actions to move the Electric Power Transmission system to open competition. (See [Johnston-95].) The technical aspects of the actions involve defining what information needs to be made available, and how that information is to be made available. The "how" is to be through open electronic data networks called "Realtime Information Networks" (RINs). The Electric Power Research Institute (EPRI) has been tasked with organizing a set of workshops to collect input and present a White Paper to FERC that proposes an implementation of the RIN [EPRI-95a]. One of these workshops was held in Chicago on Sept. 7-8, 1995. In the course of this Workshop, it was proposed that the Internet be used as the mechanism to access RIN data. Several issues and questions arose concerning the use of the Internet for this purpose. This paper attempts to address some of these issues and questions. In particular, it addresses:
This paper provides information to support the thesis that the Internet is a mature, reliable, and widely used infrastructure for the exchange of scientific, engineering, and financial data, and provides secure interaction when the end-user systems and applications are properly designed and managed.
Additionally, this paper contains a strawman design for a RIN based on an informal set of requirements and desired functionality expressed verbally at the Chicago workshop. This design is intended to clarify some issues and provide a vehicle for further discussion. An annotated bibliography is also included.
Finally, many attendees of the Workshop felt that the name (Realtime Information Network) was too generic since there are many such networks in many different disciplines, and suggested changing the name to "Transmission Service-providers Information Network", or TSIN, and the name "TSIN" is used throughout this white paper.
The term "Internet" is used in several ways:
1) "Internet" refers to the global Internet - the world's largest packet switched data communications network
2) "internet" (spelled with a lower case "i") refers to private (isolated) packet data networks that are based on Internet technology
3) "Internet technology" refers to the protocols (addressing and data transport), routing algorithms (how the path from source to destination is found), network management, tools, practices, etc., used in the Internet.
The Internet is constructed of "routers" (packet switches) interconnected by many different kinds of communication links. In the wide area, these links are usually provided by the telecommunications industry, and encompass a number of different technologies:
In local area networks (LANs of the size of offices, buildings, or campuses), Ethernet and FDDI are typical link level technologies. The Internet IP protocols run over all of these, providing "inter-networking", hence "internet protocol" or "IP". Transport protocols like TCP, UDP, and RTP use the IP network protocol for addressing and packet-level operations. (See [Hedrick] and [Comer].)
The global Internet is a loose collection of hundreds of thousands of routers operated by tens of thousands of different organizations (both users and providers). It is a consensual, ad hoc, collaboration; there is no central authority and no formal development plan. The Internet is usually conceptualized as a large "cloud" of connectivity whose internal structure is dynamic and not visible to the communicating end-user systems.
Internet Service Providers (ISPs) are companies that supply end-user system access to the cloud. (ISPs may, or may not, operate parts of the network "inside" the cloud.)
Access to the Internet by user systems is usually characterized by the bandwidth to the user site or computer system. Access may be by
The provision of connectivity and transport in the Internet using Internet Service Providers is analogous to the cable TV distribution system and the cable drops to your home provided by local cable TV systems. These systems (at least today) have the model of transport and connectivity being provided by one set of companies (cable operators) and content is supplied by another (e.g. TV Networks). On the Internet, transport and connectivity are supplied by Internet Service Providers, and content is provided by any connected computer system that chooses to do so.
Information (content) on the Internet takes the form of various combinations of:
This information may be delivered
Many different Internet tools are used to search for and deliver content via the Internet (see [Liu-95]). For example:
The client-sever concept grew out of the ARPA funded, joint development of Unix and Internet technology in the early 1970s. Servers are applications that organize and provide access to many different kinds of content (data, directory lookup, e-mail, etc.). Clients request and retrieve the content from servers on behalf (typically) of human users (e.g. WWW browsers such as Netscape and Mosaic). Servers are always available to respond to requests, clients are typically created on-demand (e.g. when a human starts a program). Modern servers and clients are "network-based" (servers may run on any system connected to your network) and clients anywhere in the network may access those servers. In the case of internet servers and clients the "network" may be the global Internet.
There are many types of servers and clients that operate automatically, both within computer systems and between Internet connected computer systems, to do all sorts of "housekeeping" functions (e.g. timekeeping, system directory services, printing, e-mail, user validation, etc.)
Protocols are the rules that are used to specify how to do addressing, format data, communicate control requests, etc., over a data communication link.
Network-level protocols specify, in a very general way, how to transport data (e.g. the TCP protocol). (See [Hedrick] for a brief introduction to Internet protocols, and [Comer] for an in-depth coverage.)
Application-level protocols organize the communication of specific types of data between clients and servers, for example (just to illustrate a few of the many application protocols):
The World Wide Web has become the primary way to access much of the information available on the Internet. The Web consists of well over 100,000 sites (servers) that provide access to millions of interconnected "documents." (Hence the term "web.")
The basic way of representing information (or "content") on the WWW is though what are called "hypertext" documents. Hypertext provides a construct called a "link" which, when activated by the user, causes a "jump" to some other document. One of the innovations that has made the WWW so powerful is the generalization of hypertext links that encompass not just being able to jump to another text document, but able to point to any sort of generalized "document" - for example, images, audio and video clips, etc. A further generalization allows the link to invoke a program (via the common gateway interface (CGI) on the server side, where the program is actually invoked) with input provided by the user (through "forms" on the client side).
The combination of these extensions to the classical notion of hypertext allows people to build interactive program interfaces that are presented via WWW browsers such as Netscape and Mosaic and that provide much of the functionality of a window system(2), but in a platform and window system independent fashion. These visual and interactive WWW "documents" are now uniformly accessible from Microsoft Windows, Macintosh, and Unix platforms. For an example of a 3D, interactive, graphical visualization based on this technology, see http://www-itg.lbl.gov/ITG.hm.pg.docs/dissect/info.html [Frog]. The platform on which the server runs is irrelevant because all of the interaction between the server and the client is governed by the hypertext transfer protocol ("http") application protocol that runs over the Internet.
There are currently many books on creating WWW sites and documents. (See, for example, [Liu-95] or [Lemay-95].)
End-user access to the Internet is provided by Internet Service Providers (ISPs). An ISP might be a University networking group, a corporate networking group, an independent commercial service provider, and (increasingly) telephone companies (Sprint, MCI, and AT&T all provide Internet access service, as have many of the regional Bell operating companies). Major players in the cable TV industry have also indicated that they will supply Internet access.
In all cases, individual end-systems (whether your lap-top PC or your Department file server) connect to Internet routers operated by service providers. The service provider connects that router to other Internet routers, or directly to one of the Internet "backbone" networks.
The end-user computer connects to the ISP routers at the "edges" of the Internet cloud through any of a variety of interfaces: Ethernet, dial-up modems, ISDN, etc. The service provider may supply the link-level connection to the interface (e.g., your corporate Ethernet LAN), or you may pay a telecommunications company to provide the connection (e.g. dial-up telephone, ISDN, dedicated circuit, etc.), depending on whether the router is located at your site or at the ISP site.
Through the world-wide telephony network the Internet is accessible from almost anywhere in the world (at low bandwidth, using dial-up telephone lines, as well as cellular and satellite telephony). Higher bandwidth, and/or dedicated circuit access, to the ISP router depends on the capabilities of local telecommunications companies (and soon, almost certainly, cable TV companies.) These connections from the ISP router to your site are sometimes called "tail circuits".
Figure 1 illustrates several strategies for connecting to the Internet.
Security is usually approached from the point of view of identifying the threats (methods of attack) and the associated risks (potential consequences of a successful attack), and then designing protective measures to address these issues (both thwarting attacks, and limiting the damage resulting from a successful attack).
Typical risks include denial of service, unauthorized access to information, unauthorized execution of an action (e.g. transaction), modification of legitimate transactions and data, etc.
While most people tend to think of threats as originating from outside the organization or legitimate community of users, most security breaches (something like 70%) occur from within. However, here we focus on external threats.
Security issues arise, and are dealt with, at several places in the network and attached systems.
First, security in the Internet itself involves the reliable operation of the routers and services essential to the operation of the transport level of the network. These elements are, relatively speaking, few in number and operated by network professionals whose full-time job is to ensure their correct operation. While no human organization or software system is free of bugs that can produce security weaknesses, the single purpose software of routers and the constant attention of people who are aware of the issues, consequences, and solutions, make the Internet infrastructure an infrequently successful target of security-oriented attacks. Successful attacks at this level would probably manifest themselves primarily as service interruptions, which are rare due to any cause, although "wiretapping" and spoofing(3) are also potential consequences of successful attacks on the Internet infrastructure.
With respect to specific applications (like the TSIN database servers), most Internet-based security attacks are indirect. That is, the object of attack is the computer system that runs the application and stores the data, rather than the application itself. The most common mode of attack is through heavily used services, such as mail and ftp, that provide external access to the system.
There are many reasons why indirect attacks are the most common, but it usually comes down to the fact that commonly configured computing systems supply many possible targets, many of which can be replicated and studied by would-be assailants. The targets are typically the servers that provide the common system services of computers attached to the Internet: mail, ftp, remote login, etc. Apart from identifying and correcting all of the design and implementation problems of all of these complex programs (a large and on-going effort by many people in the commercial and academic computer science communities), the best way to reduce vulnerability is to limit the targets or limit the access to them.
The best way to limit targets is to simplify the system. If being a TSIN data server is the only function of a system, then many of the "standard" (and well studied) services do not need to be run, and therefore will not present targets for attack.
The second common way to reduce vulnerability is to limit access by restricting what servers can be accessed from the Internet, or by permitting only known external systems to access the services. These safeguards are accomplished by "firewall" methods that operate most commonly on a router that sits between the end-user system (e.g., the TSIN data server) and the rest of the Internet, but firewall techniques can also be usefully applied on end-user systems themselves. Firewalls are an effective technique, but do not protect against things like address spoofing (a mode of attack where the assailant masquerades as a "friendly" system).
Many security breaches at the system level (both from within and from outside) are due to poor system administration practices. This issue is addressed by an increasingly large body of well publicized knowledge on safe and standard practice for running a system so that it does not inadvertently expose itself to attack, together with operating policy to ensure that safe practice is followed. This kind of information is available from books, articles, professional training, and Internet standards community documents. For example, see [CERT], [Curry-92], [Garfinkel and Spafford-91], [Harvard], [RFC-1244], and [Spafford].
Finally we come to the direct attack threats that most people associate with security issues: the compromise of the data stream and the application itself.
Techniques to address threats at this level have developed rapidly over the past few years due to the increasing interest in providing financial services over the Internet. The types of services and techniques that are now available address the issues of authenticated access, data integrity, confidentially, and (potentially) non-repudiation of transactions. Most of the techniques being adopted by the Internet financial community are based on a set of technologies known as "public key certificates."
Public Key Certificates are a combination of two technologies - public key cryptography and network directory services - that are now being used as the basis of Internet financial transaction security by a wide variety of commercial concerns (e.g. most commercial WWW browsers - Netscape and Spyglass - Mastercard, Visa, Microsoft, etc. - see [SSLNews]).
Public key cryptography uses what is known as asymmetric key-based encryption: Two associated encryption keys are generated as a pair, and documents encrypted with one key are decrypted with the other key. "Conventional" cryptography uses the same key to encrypt and decrypt, and is therefore called symmetric encryption. The DES standard for "bulk" encryption is a symmetric scheme. See the [RSA] for an introduction to public key cryptography and the excellent book by Warwick Ford [Ford-95] for an in-depth coverage of the whole field.
The asymmetric nature of public key cryptography (PKC) leads to some interesting properties that are the reason for its value and success in securing wide area network-based transactions. The most common way to use PKC is for the originator of a document to encrypt that document with one of the two keys (usually called the "private" key). The encrypted document and the other key (called the "public" key) are then both distributed widely. The public key is then used to decrypt the document. Successful decryption with the public key means that the document could only have been encrypted with the corresponding private key (and therefore by the holder of that key), and that it must be exactly the same as the document that was originally encrypted.
This technique, then, accomplishes two important goals: It verifies the authenticity of the document in-hand (it must be an exact copy of the original) and it verifies the originator (only the holder of the private key corresponding to the public key that decrypted the document could have "signed" the original).
In a useful variation of this scheme, documents encrypted using a public key can only be decrypted using the corresponding private key, thus providing a means for anyone in possession of the public key to correspond in guaranteed privacy with the holder of the private key.
Public key technology is useful in and of itself, but a number of other concepts and supporting infrastructure are needed to make it the useful and powerful tool that it is today, and this brings us to certificates.
The pivotal issue is how public keys are generated, irrefutably associated with a know entity (person, corporation, etc.), and then distributed so that the originator of a document can be both identified and verified.
One important concept is that of Certification Authorities, and how they work. (See [Kent] and [Ford-95].) The problem to be solved is how you associate a public key with an entity (e.g. person), and then distribute that public key so that the relationship (of entity to key) cannot be counterfeited. This is accomplished in the following way. A Certification Authority ("CA") is a trusted third party that verifies the identity of an individual (or other "entity"), issues a public/private key pair, and then makes publicly available the identity and the corresponding public key of the registrant. The individual, of course, must keep the private key completely confidential.(4)
The identity and the public key are placed in a document that the CA then "signs" with its private key(5). This document - the "certificate" - is then made publicly available, typically through some sort of network accessible database.
The recipient of a "certified" document retrieves the public key certificate of the presumed author, decrypts and/or verifies the certificate with the public key of the CA, extracts the author identity and public key, and then finally decrypts the original document. Successful decryption of the original document (or its seal) now verifies its authenticity and the identity of the author. This, then, is the basis of secure authenticated Internet transactions in an open, scalable, and public network.
There are two other important details to address in order to complete the conceptual framework of public key certificates.
Public key certificates are distributed from network accessible databases. While many variations are possible, the current trend is to use the X.500 network directory server. The primary use of directory servers is to permit e-mail addresses, postal addresses, telephone numbers, etc. to be found for individuals. However, X.500 servers can also supply public key certificates (in a standard form, called an X.509 certificate). These servers are available from anywhere on the Internet and are typically maintained by the parent organization (e.g. a company, university, government laboratory, etc.). This infrastructure, then, provides for the wide distribution of identity-public key information.
The second remaining detail is who issues the certificate and verifies identity. Currently this is done by certification authorities typically associated with a particular community of users. So, for example, Apple Computer has a distributed collaboration environment in which "strong" user authentication is required. To support this activity Apple runs a certification authority. In order to register with this CA (and be issued a public/private key pair) an individual must present documents such as a birth certificate and drivers license to a Notary Public, who signs the registration form. On this basis, the CA provides a certain level of "guarantee" for identity of the individual associated with the public key. (See [Baum-94] for a detailed discussion of certification authorities and their legal and sociological implications.) RSA, Inc. - the provider of most commercial implementations of public key technology - also runs a CA. Large scale CAs in the future will probably be run by the U. S. Postal Service. The USPS CA will provide several levels of certification (identity guarantees) ranging from anonymous to biometrically verified (e.g. retina scan). USPS sees this, and a variety of other cryptographically-based services, as one of its major commercial services in the future. (See [USPS].)
Given the techniques of public key certificates and the infrastructure of network directory servers, security services and protocols can be developed to address the application-level security issues. The services define how an application obtains security service, and the protocols specify how to use the basic information and verification techniques (i.e. what information is presented, when, in what order, etc.) in order to accomplish "strong" user (and server) authentication, confidential and verifiable transactions, etc. Description of the services and protocols is beyond the scope of this overview, but examples include the Generic Security Service Application Program Interface ([GSSAPI]) and the Secure Socket Layer protocol (see [SSLProtocol]).
Two more comments are needed in the interest of completeness. The first is that public key cryptography is almost always used in conjunction with symmetric cryptography (e.g., DES). PKC is used for the authentication and then to provide secure messaging to exchange temporary secret keys for DES encryption/decryption. These temporary keys are sometimes called "session keys". The reason for this is that the DES is much more computationally efficient for "bulk" encryption of data streams.
An important final note is the following. As we have seen, security is a many faceted thing, involving policy, operational practice, network servers, client programs, etc. At the most elementary level there are two types of computer code whose correctness is essential for the underlying concepts to provide security. The first is the cryptographic algorithms themselves (e.g. DES) and the second is the protocols that use these basic algorithms to accomplish things like user authentication. Experience has shown that good implementations are those that have stood the test of time (and attacks), and have had their weaknesses identified and corrected. Weaknesses can occur in the protocols (somewhere in a sequence of operations, a critical piece of information is inadvertently exposed) or in the computer code that implements the algorithms and protocols. A good example of this process was reported in a article in the New York Times [NYT-9-19-95]. The Secure Sockets Layer [SSL] used by Netscape for their WWW transaction security is a protocol. Part of the implementation of this protocol involves generating encryption keys on the fly (session keys). Such keys require a "seed" number to generate. If the seed is not a random number, it may be possible to break the encryption. The Netscape implementation made the mistake of using the system time as part of the seed, thus making it possible to break the encryption based on the keys generated with those seeds. Two Computer Science graduate students discovered the weakness, broke the encryption, and announced the fact on an Internet bulletin board. Netscape will now change the way it generates seeds, carefully re-examine the rest of its code, and a more mature and unbreakable security will be the result. In other words, their implementation will have moved toward the maturity that makes for really strong security.
Internet access service is now a commodity. Thousands of service providers supply service to millions of users. The two principal ways to gain access to the Internet are through direct connection via an Internet Service Provider, and through indirect connection via a timesharing service.
A random sampling of a few dozen Internet service providers from a list of 1300 service providers listed at one WWW site (http://thelist.com/) gave the (rough average) results indicated below.
28.8 Kb/s dial up service$27/mo
ISDN dial-up service (64 Kb/sec)$60/mo
56 Kb/sec, dedicated$300/mo
T1 (1.15 Mb/sec) dedicated$1300/mo
Recall from the discussion above that this is one component of three required for Internet access: Internet Service Provider, local telecommunications access, and a local piece of hardware to connect from the telecommunication connection to your computers.
The local telecommunications access varies widely from state to state (depending on the state regulatory situation), but in California, for example, a very rough approximation is that the telecommunication costs are about equivalent to the ISP costs.
The hardware required ranges from a few hundred to a few thousand dollars, and within the first year will generally be small compared to the combined service and telecomm costs.
The "bulk" of the users of the Internet will probably gain access to the Internet through VARs that run timesharing systems. These timesharing systems tend to be thematic (oriented toward a particular market segment) and typically supply restricted access to the Internet (via the WWW, telnet, and ftp). Delphi, America Online, and Prodigy are such VARs, and Microsoft and AT&T have recently announced similar services. By way of example [NYT-9-20-95], AT&T's new "Business Network" provides access to business bulletin boards and "access to the World Wide Web via Netscape Communications Navigator software that is included in the package, Internet chat groups and discussion groups related to business topics orchestrated by AT&T." "The service will cost $39.95 a month for the first 10 hours of use and $2.95 for each additional hour." The Microsoft offering is similarly structured. These services can usually be accessed through the Internet, but the most common way is by dial-up access to the timesharing system (and from there through a gateway to the Internet). AT&T is also an Internet Service Provider through it "AT&T World Net Service".
For large sites (universities and corporations) that deal directly with "regional" Internet Service Providers, the Internet is highly reliable. Part of the reason for the reliability is that it is not difficult to configure alternate paths to the Internet "cloud". (Multiple paths through the cloud are an automatic part of the Internet operation, and reflect the fact that the Internet technology was originally designed as a "survivable" network for military use.) Alternate paths can be provided into the Internet cloud, and even (for a "small" number of sites) around the cloud (i.e. a "private" internet). These possibilities are illustrated in Figure 2.
In this section we present a strawman design for both a system architecture and a data management architecture for the TSIN. The purpose of this strawman is principally to illustrate one approach to providing TSIN service and Transmission Open Access (TOA) data using the WWW and the Internet.
The "requirements" for the design are taken from the discussions at the Sept., 1995 Real-Time Information Networks (RINs) Implementation workshop ([EPRI-95b]), together with some other constraints imposed to simplify the architecture.
The "requirements" from [EPRI-95b] reflected in the design include:
How the requirements are met, plus some "implied, derived, or added" conditions to be able to produce a simple, illustrative design are as follows:
The strawman TSIN node "security and data flow architecture" is illustrated in Figure 3, and the data management architecture is illustrated in Figure 4.
Mary-Ann Scott, Office of Energy Research, Office of Computation and Technology Research, Mathematical, Information, and Computational Sciences (MICS) Division, of the U. S. Department of Energy provided the motivation for this white paper; R. L. Fink, D. F. Stevens, and F. Olken of LBNL provided comments that increased its clarity.
M. Baum, "Federal Certification Authority Liability and Policy: Law and Policy of Certificate-Based Public Key and Digital Signatures", Published by: U. S. Dept. of Commerce, NIST, June, 1994.
From ftp://ftp.cert.org/pub/cert_faq:
"The CERT Coordination Center is the organization that grew from the computer emergency response team formed by the Defense Advanced Research Projects Agency (DARPA) in November 1988 in response to the needs exhibited during the Internet worm incident. The CERT charter is to work with the Internet community to facilitate its response to computer security events involving Internet hosts, to take proactive steps to raise the community's awareness of computer security issues, and to conduct research targeted at improving the security of existing systems."
Douglas Comer, "Internetworking with TCP/IP", Volumes 1, 2, and 3, Prentice Hall
These books are the "standard" textbooks on TCP/IP.
David Curry, UNIX System Security: A Guide for Users and System Administrators. Reading, MA: Addison-Wesley Publishing Co., Inc., 1992. (ISBN 0-201-56327-4)
Electric Power Research Institute, Power Delivery Group, "Real-Time Information Networks (RINs) Implementation Information". A WWW page at http://www.epri.com/org/pdg/ssos/rin/rininfo.html
Electric Power Research Institute, Power Delivery Group, "EPRI RIN Working Group Summary Presentations of `How' Transmission Service Information Networks (TSINs) will Operate". A WWW page at http://www.epri.com/org/pdg/ssos/rin/wrkgrp.html
Warwick Ford, Computer Communications Security: Principles, Standards, Protocols, and Techniques, Prentice Hall, Englewood Cliffs, New Jersey, 07632, 1995. ISBN 0-13-799453-2.
David Robertson, William Johnston, and Wing Nip, "Virtual Frog Dissection: Interactive 3D Graphics Via the WWW," Proceedings, The Second International WWW Conference `94: Mosaic and the Web, Chicago, IL (1994). (Available at http://www-itg.lbl.gov/vfrog/WWW.94.paper.html.)
From the paper:
"We have developed a set of techniques for providing interactive 3D graphics via the World Wide Web (WWW) as part of the `Whole Frog' project. We had three goals: (1) to provide K-12 biology students with the ability to explore the anatomy of a frog with a virtual dissection tool; (2) to show the feasibility of interactive visualization over the Web; and (3) to show the possibility for the Web and its associated browsers to be an easily used and powerful front end for high-performance computing resources."
"We have developed techniques to utilize the Common Gateway Interface (CGI) capability of WWW servers to provide an interactive 3D visualization front end through Web clients. These techniques have been used to make a `Virtual Frog Dissection Kit'. A student using this kit has the ability to view various parts of a frog from many different angles, and with the different anatomical structures visible or invisible. For example, the student can press `form' buttons that indicate that he or she wants to view the frog from above, with the exterior and skeleton removed. An advantage to this technique, as opposed to dissecting a real frog, is that undissection is as easy as dissection."
"The kit has a forms -based interface. Form submission results in a call to a CGI script, which in turn contacts a continuously running process on a more powerful machine to accomplish the graphics rendering of a large 3D data set representing the frog and its internal organs. The resulting image is converted to Graphics Interchange Format (GIF) encoding. When that process completes generation of the image, it passes the location of the image file and control back to the script which rewrites the image on the client. While this might sound awkward, the overall process is quite similar to how [conventional] rendering systems work, [where] the image [is] being written into a local frame buffer, or sent across the network as an X-window image."
Also see http://george.lbl.gov/frog .
Simson Garfinkel and Gene Spafford, Practical UNIX Security. Sebastopol, CA: O'Reilly & Associates, Inc., 1991. (ISBN 0-937175-72-2)
J. Linn, "Generic Security Service Application Program Interface, Version 2", an Internet Engineering Task Force draft from the Common Authentication Technology Working Group (http://www.ietf.cnri.reston.va.us/html.charters/cat-charter.html). The GSSAPI document is at ftp://ds.internic.net/internet-drafts/draft-ietf-cat-gssv2-03.txt .
From the Abstract:
"The Generic Security Service Application Program Interface (GSS-API), as defined in RFC-1508, provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification defines GSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications:
Harvard University, "Information Security Handbook", gopher://gopher.harvard.edu:70/00/.vine/providers/oit/Computer_Security_Handbook/Information_Security_Handbook/
From the Background section:
"An Information Security Working Group has been organized to review issues of safekeeping and confidentiality of information resources, identify risks, raise consciousness in the community and, where appropriate, develop policy statements, advisories, and guidelines. The working group has representatives from almost all the schools and major central administration departments. The intention is to build consensus among these groups, promote common definitions, compile good practices and check lists in the form of an Information Security Handbook which will be published and updated as the need arises.
While the effort was initially intended to look at administrative computer systems and the electronic distribution of data to the desktop, it was felt that the security issues of paper files, library, and research data could not be excluded. Many of the security practices recommended in the handbook are already standard practice for paper documents; they need to be extended to electronic forms of information as well. Moreover, the integration of systems across mainframes, minicomputers, microcomputers and networks makes it impossible to separate many of the concerns by application type. Security issues must be considered across many environments and media, including paper, which are increasingly shared among a heterogeneous community of users. Many of the people involved in this working group and in the University at large have cross functional responsibility and must look at security issues across their entire organizations."
Charles L. Hedrick "Introduction to the Internet Protocols" (Available from http://www.aetc.af.mil/tutorials/ipintro.html or ftp://nic.merit.edu/introducing.the.internet/intro.to.ip)
This document is a brief introduction to the Internet networking protocols (TCP/IP). It includes a summary of the facilities available and brief descriptions of the major protocols in the family.
IRC stands for "Internet Relay Chat".
From http://www.main.com/dms/irc.html :
"It was originally written by Jarkko Oikarinen (jto@tolsun.oulu.fi) in 1988. Since starting in Finland, it has been used in over 60 countries around the world. It was designed as a replacement for the "talk" program but has become much more than that. IRC is a multi-user chat system, where people convene on "channels" (a virtual place, usually with a topic of conversation) to talk in groups, or privately. IRC is constantly evolving, so the way things to work one week may not be the way they work the next. Read the MOTD (message of the day) every time you use IRC to keep up on any new happenings or server updates. IRC gained international fame during the 1991 Persian Gulf War, where updates from around the world came across the wire, and most irc users who were on-line at the time gathered on a single channel to hear these reports. IRC had similar uses during the coup against Boris Yeltsin in September 1993, where IRC users from Moscow were giving live reports about the unstable situation there."
"IRC works when the user runs a "client" program (usually called `irc') which connects to the irc network via another program called a "server". Servers exist to pass messages from user to user over the irc network."
"Realtime Information Networks for Open Access to Electric Power Transmission Facilities" an informational WWW Page at http://www-itg.lbl.gov/~johnston/EDM/FERC-NOPRA.html
Kehoe
Brendan P. Kehoe "Zen and the Art of the Internet: A Beginner's Guide to the Internet" Available from gopher://nic.merit.edu:7043/0/introducing.the.internet/zen.txt or http://sundance.cso.uiuc.edu/Publications/Other/Zen/zen-1.0_toc.html .
This is a bit dated (no information on the WWW) but a classic introduction to the Internet.
Steve Kent, "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC-1422, http://ds.internic.net/rfc/rfc1422.txt .
RFC-1422 establishes the conceptual framework for certification authorities. The hierarchical authority chain defined in the RFC will probably be modified in the next version of the document, but most of the concepts are still valid. From the RFC:
"This document defines a supporting key management architecture and infrastructure, based on public-key certificate techniques, to provide keying information to message originators and recipients......
The key management architecture described in this document is compatible with the authentication framework described in CCITT 1988 X.509. This document goes beyond X.509 by establishing procedures and conventions for a key management infrastructure for use with Privacy Enhanced Mail (PEM) and with other protocols, from both the TCP/IP and OSI suites, in the future. There are several motivations for establishing these procedures and conventions (as opposed to relying only on the very general framework outlined in X.509):
Laura Lemay, "Teach Yourself Web Publishing in a Week," Published by Sams Publishing, 1995. ISBN 0-672-30667-0 (Tel: 1-800-428-5331, http://www.mcp.com/cgi-bin/do-bookstore.cgi)
"This book covers HTML 2.0, images, sound and video, servers, CGI, forms, and imagemaps. In addition, unlike most other books about HTML, this book will teach you about how to create well-designed, easy to navigate and maintainable Web presentations with information about design, organization, and effective linking."
Cricket Liu, Jerry Peek, Russ Jones, Bryan Buus & Adrian Nye, "Managing Internet Information Services: World Wide Web, Gopher, FTP, and more," O'Reilly & Associates, 1995. (http://www.ora.com, Tel: 1-800-889-8969), ISBN: 1-56592-062-7.
"This comprehensive guide describes how to set up information services and make them available over the Internet. It discusses why a company would want to offer Internet services, provides complete coverage of all popular services, and tells how to select which ones to provide. Most of the book describes how to set up Gopher, World Wide Web, FTP, and WAIS servers and email services."
Lombard Institutional Brokerage, Inc. "Real-Time Trading and Research Information" http://www.lombard.com/
From the introduction:
"Welcome to the Lombard Institutional Brokerage Real-Time Trading and Research Information Center. Our philosophy is simple: `Through the use of cutting edge technology, we are dedicated to providing our customers in the Internet community with a wide variety of investment options, enhanced investment tools and an unparalleled commitment to customer service...' "
For an example of a trading system interface, specifically see the Lombard demonstration at http://www.lombard.com/Demo/
Michael R. Macedonia and Donald P. Brutzman, Naval Postgraduate School, "MBone Provides Audio and Video Across the Internet," IEEE COMPUTER magazine, pp. 30-36, April 1994.
From ftp://taurus.cs.nps.navy.mil/pub/mbmg/mbone.html:
"Short for Multicast Backbone, MBone is a virtual network that has been in existence since early 1992. It was named by Steve Casner of the University of Southern California, Information Sciences Institute and originated from an effort to multicast audio and video from meetings of the Internet Engineering Task Force. Today, hundreds of researchers use MBone to develop protocols and applications for group communication. Multicast provides one-to-many and many-to-many network delivery services for applications such as video conferencing and audio where several hosts need to communicate simultaneously. The magic of MBone is that teleconferencing can be done in the hostile world of the Internet where variable packet delivery delays and limited bandwidth play havoc with applications that require some real-time guarantees. Limited experiments demonstrated the feasibility of audio over the ARPAnet as early as 1973. However, only a few years ago, transmitting video across the Internet was considered impossible. Development of effective multicast protocols disproved that widespread opinion. In this respect, MBone is like the proverbial talking dog: It's not so much what the dog has to say that is amazing, it's more that the dog can talk at all!"
"The key network concepts that make MBone possible are IP multicast and real-time stream delivery via adaptive receivers. For example, in addition to the multicast protocols, many MBone applications are using the draft Real-Time Protocol on top of the User Datagram Protocol and Internet Protocol. RTP, being developed by the Audio-Video Transport Working Group of the Internet Engineering Task Force, provides timing and sequencing services, permitting the application to adapt and smooth out network-induced latencies and errors."
Also see the "Mbone Homepage" http://www.best.com/~prince/techinfo/mbone.html and http://www.rpi.edu/Internet/Guides/decemj/itools/cmc-mass-mbone.html
J. Markoff, "Security Flaw is Discovered in Software Used in Shopping", the New York Times Front Page, Sept. 19, 1995
L. Zuckerman, "AT&T Starts On-Line Service Aimed as Small Business", the New York Times Business Section, Sept. 20, 1995
"Site Security Handbook" (available from ftp://nis.nsf.net/internet/documents/rfc/rfc1244.txt or ftp://ds.internic.net/rfc/rfc1244.txt)
"This handbook is the product of the Site Security Policy Handbook Working Group (SSPHWG), a combined effort of the Security Area and User Services Area of the Internet Engineering Task Force (IETF)."
"This handbook is a guide to setting computer security policies and procedures for sites that have systems on the Internet. This guide lists issues and factors that a site must consider when setting their own policies. It makes some recommendations and gives discussions of relevant areas."
http://www.rsa.com/rsalabs/faq/faq_home.html
From the introduction to the FAQ:
"This is an introduction to modern cryptography, including answers to commonly asked questions about public key algorithms such as RSA, ElGamal and Diffie-Hellman; secret key techniques such as DES, RC2 and RC4; and hash functions such as MD, MD2, MD5 and SHA. Certificates, key management, patents, Kerberos, discrete log, factoring, domestic and international standards are also among the topics discussed."
"New in this edition is expanded treatment of recent government involvement in encryption policy and standards, including discussions on the controversial Capstone, Clipper and DSS proposals, export controls, NIST, NSA, privacy and intellectual property concerns."
"COAST/Spaf's Hotlist: Computer Security, Law & Privacy" http://www.cs.purdue.edu/homes/spaf/hotlists/csec.html
This is a WWW site with many pointers to security related information:
- FIRST Teams (Forum of Incident Response and Security Teams)
Netscape Communications Corporation, "Netscape SSLRef" (http://home.netscape.com/info/sslref.html):
"SSL is Secure Sockets Layer, an open, publicly available and license-free security protocol specification suitable for use on the Internet and other TCP/IP networks in a broad range of contexts. It can be used with application-level protocols such as HTTP, FTP, Gopher, Telnet, NNTP, rdist, and many others (including protocols yet to be invented).
The SSL protocol enables advanced security in an application using a variety of mechanisms which include authentication, confidentiality and integrity.
The full protocol specification has been available to software developers and the Internet community since last October.
Netscape Communications Corporation, "Industry Leaders Support Secure Sockets Layer for Internet Security" (A "news release". (http://home.netscape.com/info/newsrelease17.html):
"MOUNTAIN VIEW, Calif. (March 20, 1995) -- Netscape Communications Corporation today announced that a number of industry-leading companies and organizations are supporting the Secure Sockets Layer (SSL) protocol for Internet security. Apple Computer, Inc., Bank of America, ConnectSoft, Delphi Internet Services Corporation, Digital Equipment Corporation, First Data Corporation, IBM, MarketNet, MasterCard International Inc., MCI Communications Corp., Microsoft Corporation, Novell, Inc., Open Market, Prodigy, Silicon Graphics, Inc., StarNine, Sun Microsystems, Inc., Visa International, and Wells Fargo are among companies backing SSL.
SSL is an open protocol for securing data communications across computer networks. The broad support for this protocol will promote interoperability between products from many organizations and will speed the growth of electronic commerce on the Internet and private TCP/IP networks. Today, more than 3 million people are already using SSL-enabled products, which have been available since December 1994. In October 1994, Netscape published the specification for SSL on the Internet. Recently, the company also published the source code to the reference implementation, called SSLRef, on the net. SSLRef is free for non-commercial use and is available for flat-fee licensing by companies who want to use it in commercial products."
Netscape Communications Corporation, "The SSL Protocol", http://home.netscape.com/info/SSL.html
William Stallings, Network and Internetwork Security, Prentice Hall, Englewood Cliffs, New Jersey, 1995. (ISBN: 07803-1107-8)
William Stallings, Protect Your Privacy - A Guide for PGP Users, Prentice Hall, Englewood Cliffs, New Jersey, 1995. (ISBN: 0-13-185596-4)
This book is Stallings' description of Phil Zimmerman's PGP system.
Informal discussions with the Electronic Commerce Services group of the U. S. Postal Service about their electronic commerce services plans, especially for certificates, indicates the following.
USPS is organizing their certificate services around a Certification Authority (CA) that they will run without reference to a higher authority (e.g. the IRPA). Like many others who are running CAs, USPS intends to set its policy in accordance with what they think that their commercial customer base will find most useful. USPS expects to see a number of "high level" CAs (like USPS) cooperate by signing each other's certificates in order to allow for inter-operation. (Steven Kent, IETF PEM Working Group Chair. recently indicated that the IETF would soon set up a working group to review and revise the RFC-1422 CA model.)
USPS will issue two classes, and several subclasses of certificates: