gainst gross misuse rather than more insidious attacks. After all, the resources within this portion of the intranet are intended to be shared.
The inner firewall, however, protects more-sensitive resources, including production systems and proprietary data resources. It's therefore considerably more restrictive in the packets it allows to pass.
Exposing any more of the organizational intranet to the outside can be quite risky. When the resources to be shared on the extranet must be maintained
on more-sensitive internal systems, one approach is to use an object request broker (ORB) that sits outside an inner firewall and accepts -- and handles -- requests for resources. The ORB responds to requests from the outside by relaying them inward using IIOP and connecting to an ORB on the inside of the intranet. When the interacting objects are designed correctly, outsiders are able to access only the data for which they are authorized (see the figure
"Extranet-Enabling Objects"
).
The use of ORBs allows extranet us-ers to have limited access to information and processes that live inside the private portion of an intranet, even though the actual systems through which this information is distributed live outside the physical borders of the extranet.
Authenticating Extranet Users
No matter how the extranet user population is determined, defining this population should be one of your first tasks. It will likely become the most important factor to drive your extranet s
ecurity, infrastructure, and applications.
The use of simple user IDs and password-access control is sufficient to protect resources as long as the transmission of password and user IDs is kept private. As more resources are made available through networks, particularly open ones, plaintext transmission of passwords and user IDs becomes less acceptable.
User-authentication tools are necessary, but they are not sufficient to protect valuable resources from unauthorized access. They can be vulnerable to man-in-the-middle eavesdropping, social engineering, and other routes of attack. But these tools can help keep out most casual attackers as well as keep track of resource use.
SecurID ACE
Access control encryption (ACE) is the system used in the Security Dynamics SecurID hardware-token system. SecurID tokens, which are about the size of a credit card (though noticeably thicker), have been used for secured access to organizational networks since the 1980s.
When SecurID ACE users
attempt to connect to a protected resource (usually a network, through an ACE server), they are prompted for their user name and a passcode (i.e., the number displayed on the SecurID card, or token, and a personal identification number, or PIN). Then the following sequence of events occurs:
- The server retrieves the PIN and a seed number associated with the SecurID card assigned to the user name.
- The server uses another mechanism (using data from previous connections) to attempt to estimate the current clock "drift" associated with the internal timekeeping of the token.
- The server calculates the correct token passcode, including the PIN, and determines how long that passcode will be accepted as valid authentication.
The passcode is the product of a hashing function that starts with the token's secret key and the current time to generate a time-limited product. The token generates these values continuously, but the server calculates this value when a user attempts to conn
ect to the resource.
The token's secret key, the product of the key, and the current time are never transmitted; rather, a cryptographic hash (or digest) function is applied to the re-sult to produce a much smaller value (but still too large to be susceptible to guessing). If the server comes up with the same value as the user who is attempting to log in, access is allowed. The result is a two-part authentication:
- The user enters a correct PIN to indicate knowledge of a shared secret. (The user and the server share this data.)
- The user enters a correct passcode to indicate possession of the token.
Bellcore S/Key
The risk of using a hardware token for user authentication is that the token can be lost or stolen. Also, if the PIN (which is usually shorter than the typical stand-alone password) can be compromised, a criminal can be authenticated as an authorized user. Bellcore's software-only solution, S/Key, generates one-time passwords based on a password known
only to the user and not stored on any system.
S/Key requires only that the server side of the resource be modified. It uses one-time passwords that do not require encryption or any other special treatment through the client. Each time the user logs in, a different password is used; intercepting it would be of little use to anyone.
A sequence of one-time passwords is generated with a one-way hashing function (i.e., a function that modifies input so that it can't be determined simply from the output). S/Key usually uses the MD5 message digest function (sometimes the MD4 function is used) to generate a list of one-time passwords for the user. (These passwords can be either printed out or generated on the user's client system.)
The key to S/Key is that it uses passwords in the reverse order from which they're generated so that the one-way nature of the hashing function can be used to authenticate the user. It works like this:
- The user enters a secret password in a direct (e.g., a
t the host console) or secure (e.g., encrypted telnet) connection with the host.
- The S/Key host software uses that password and an internal, randomly generated key to create a seed value for the password list.
- The S/Key host hashes the seed value repeatedly, storing only the last value calculated. Typically, the digest function is run 99 times, with the S/Key host storing only the ninety-ninth value, along with the random value generated to seed the hashing process and the user ID.
- The user logs in to the S/Key host for the first time and is prompted for the ninety-eighth password (if the one stored on the host is the ninety-ninth value). The S/Key host runs the hashing function on the password that's sent by the user; if the result is the value stored, the user is permitted access.
- The S/Key host replaces the previously stored password value (the ninety-ninth value) with the password that was just used (the ninety-eighth value). The next time that the user logs in, the ninety-seventh hash
value must be used to produce the stored value when the hashing function is run.
Like any security mechanism, S/Key is not 100 percent bulletproof. For example, it can be defeated if a criminal is able to steal the list of passwords or get access to the system storing the user's passwords. However, S/Key is potentially safer than sending reusable passwords in the clear over the Internet.
Password Authentication Protocol
Originally designed as a simple method for a host to authenticate itself to another host while using the Point-to-Point Protocol (PPP), the Password Authentication Protocol (PAP) is described in detail in RFC 1334, "PPP Authentication Protocols." Very simply, PAP is a two-way handshaking protocol in which the host making the connection (the
peer
) sends a user ID and password pair to the system with which it's trying to establish a connection (the
authenticator
-- although not all PPP links require authentication).
PAP is two-way because it us
es a simple, two-step process. The peer sends its authentication data, and the authenticator acknowledges approval of the peer. PAP authentication can be used at the start of the PPP link as well as during a PPP session to reauthenticate the link.
Once the PPP link is established, PAP authentication can be carried out over that link. The peer sends a user ID and a password in the clear to the authenticator until either the authenticator accepts the pair or the connection is terminated. PAP is not secure: Authentication information is transmitted in the clear, and nothing protects against playback attacks or excessive repetition by attackers trying to guess a valid password/user ID pair.
Challenge Handshake Authentication Protocol
Documented in RFC 1994 ("PPP Challenge Handshake Authentication Protocol [CHAP]"), which supersedes RFC 1334, CHAP provides a more secure mechanism for authenticating PPP links. Like PAP, CHAP can be used at the start of a PPP link and then repeated after the lin
k has been established.
CHAP is referred to as a
three-way handshake protocol
because it incorporates three steps to produce a verified link after the link is first initiated (or at any time after the link has been established and verified). Instead of a simple two-step password/approval process, CHAP uses a one-way hashing function in a fashion similar to that used by S/Key. MD5 is specified as a requirement of the protocol, although other functions can be supported. The actual process goes like this:
- The authenticator sends a challenge message to the peer.
- The peer calculates a value using a one-way hash function and sends it back to the authenticator.
- The authenticator can acknowledge authentication if the response matches the expected value.
The process can be repeated at any time during the PPP link to ensure the connection has not been taken over or subverted in any way. Unlike PAP, which is driven by the client side, the server controls CHAP reauthen
tication. CHAP also removes the possibility, inherent in PAP, that an attacker can repeatedly try to log in over the same connection. When the CHAP authentication fails, the server is required to drop the connection. This complicates the task of password-guessing.
Remote Authentication Dial-In User Service
CHAP, though a stronger method than PAP for authenticating dial-up users, is not inherently as scalable a protocol as large organizations might need. Even though it doesn't transmit any secrets across a network, it requires lots of shared secrets to be run through the hash function. Organizations with many dial-up users must maintain very large databases to accommodate them all.
The Remote Authentication Dial-In User Service (RADIUS) protocol, described in RFC 2058, uses a client/server model to securely authenticate and administer remote network connection users and sessions. RADIUS is largely a way to make access control more manageable, and it can support other types of user authenti
cation, including PAP and CHAP.
The RADIUS client/server model uses a network access server (NAS) to manage user connections. Although the NAS functions as a server for providing network access, it also functions as a client for RADIUS. The NAS is responsible for accepting user connection requests, getting user ID and password information, and passing it securely to the RADIUS server. The RADIUS server returns authentication status (approved or denied), as well as any configuration data required for the NAS to provide services to the end user.
By providing a single point of access while supporting multiple authentication schemes out of multiple systems, RADIUS simplifies the task of securing access to different resources within an internetwork. RADIUS clients and servers communicate securely, using shared secrets for authentication and encryption for transmitting user passwords.
Terminal Access Controller Access-Control System
Terminal Access Controller Access-Control System (TACACS
) is a protocol specification, described in RFC 1492, that can administer authentication, authorization, and accounting data for users logging in. TACACS is currently best known as Cisco System's server-based security software protocol. All Cisco router and access-server product families use this protocol.
TACACS employs a centralized server -- either a special TACACS database or the Unix password file with TACACS protocol support -- to which all authentication, authorization, and accounting data is directed when a user tries to log in. For example, a Unix server supporting TACACS passes requests to the Unix database and returns the accept or reject message to the access server.
TACACS transmits all data in the clear between the user and the server, but a recent update from Cisco, TACACS+, adds a message-digest function to eliminate the plaintext transmission of passwords. TACACS+ also supports multiprotocol log-ins, meaning that a single user ID and password pair can authenticate a user for mult
iple devices and networks (e.g., an IP network log-in and an IPX network log-in). Finally, TACACS+ can also handle PAP and CHAP authentication.
Protecting Corporate Assets: Packet Filtering
By its nature, the TCP/IP protocol suite makes it relatively easy to set up rules for filtering packets that are traveling in either direction (in or out) through an internetwork router. Every IP datagram includes data about its destination, source, and contents. Because each IP datagram passing in or out of an internetwork can be forced to go through a single point (the firewall gateway), each one can be checked against a list of rules to determine if it should be allowed to pass.
Packet-filtering rules use the information in the IP datagram to determine what is and is not permitted to pass through the firewall (see the figure
"Packet-Filtering Techniques"
). Generally accepted practice is to be strict (prohibiting anything that is not explicitly permitted) rather than to be liber
al (permitting anything that is not expressly prohibited).
The firewall gateway doing the filtering checks every packet, incoming and outgoing, and compares it to the list of rules. If the packet is for a service (e.g., FTP) going to an allowed port (e.g., port 23) on a host on a permitted network, then it's forwarded; otherwise, it's blocked.
Packet filtering seems to offer an excellent way to ensure network integrity. More difficult, however, is creating a list of rules that can be relied upon to always keep out intruders and to never (or rarely) disrupt normal operations.
Moreover, people can find many ways to avoid most packet-filtering rules. For instance, some companies use packet filtering to keep employees from accessing the Web. But devious employees can still do their Web surfing through such packet filters by using an alternative protocol to connect to a host outside the network and then tunneling their Web sessions through that permitted link. A user can tunnel HTTP transfers wit
h a telnet connection through a firewall that prohibits connections to external HTTP servers but permits access to telnet servers (see the figure
"Tunneling Protocols"
).
Packet filtering keeps out certain types of casual intruders and might slow down more sophisticated ones; it might also limit use from inside an organization. The way in which TCP/IP application protocols operate makes the filtering of outbound packets as important as filtering inbound packets.
For example, FTP uses two virtual circuits during file transfer: one initiated by the client to connect to the server (this circuit carries control information, such as client requests and response codes, from the server) and the other initiated by the server, in response to a client request for a file, to carry the actual file transfer. If a packet filter permits outbound FTP sessions, it must also permit at least some inbound FTP session traffic. Otherwise, users would be able to open a file transfer session without
being able to transfer any files.
Packet filtering presents other drawbacks as well. Once you allow access to an internal host, you cannot control what happens on that host. This loophole permits a remote user to attempt to exploit any security weakness in that host -- and possibly using that host's access to other hosts on the network.
Also, packet filters use the information stored in IP datagram headers, which means that attackers can do
IP spoofing
-- counterfeiting the source IP address of the datagram, making the gateway believe it comes from an authorized host.
Circuit Gateway
Another approach to protecting internal hosts from attack is to have the firewall system act as an intermediary for all application exchanges. In other words, internal hosts pass all session requests through the firewall, which forwards them to the remote server as if they were coming directly from the firewall. The remote server then responds to the request by replying directly to the firewall,
which relays the response to the internal host. Both the internal and external systems connect directly to the firewall, which relays all messages between the two.
Circuit-level gateways act to eliminate access to unauthorized servers on the protected network. This security measure provides a certain amount of protection from attacks that originate from within an organization. Server software can be configured to listen to a nonstandard transport layer (where circuits are created in TCP/IP networking) port, allowing access by unauthorized users from outside the protected network, even if packet filtering is turned on. Circuit gateways can eliminate this risk because they deny all unsolicited incoming requests.
On the downside, circuit gateways often require that systems inside the gateway use special versions of TCP/IP client application software to support the indirect connection with external hosts through the circuit gateway. Consequently, all users within an organization wishing to go through
the firewall to access services outside the firewall need to have special copies of the client application software; standard clients are denied access through the firewall. And, of course, because no inbound client requests are permitted, circuit gateways support a limited level of service.
Application Proxies
Whereas circuit gateways use special software to provide the interface between the application client inside the firewall and the application server outside the firewall, an application gateway provides the same service seamlessly. The firewall acts as a proxy for the client when a service is requested and passes responses from the server back through to the client.
An advantage of application gateways is that you can configure them to pass external requests in to approved servers. This technique is possible because all requests to open well-known ports are funneled through a single point: the application gateway.
Because they're involved directly in every application interch
ange between clients and servers inside and outside the firewall, application gateways can do very detailed logging of all those connections -- and of all attempted connections. Logging failed attempts to break into systems on an intranet can be invaluable in tracking down the source of the attacks. And, of course, when combined with network-administrator notification systems, firewall gateways can alert intranet managers to an attack in progress.
Application gateways mediate all client and server connections to systems outside the intranet, a task that can be very computer intensive. One potential problem is that application gateways can become a performance bottleneck, particularly as the number of simultaneous sessions increases.
Nested Security Zones
The purpose of traditional firewalls is very simple: to separate an intranet from the Internet. Extranets, however, are often designed to provide some degree of permeability to access via the Internet. Using multiple firewall systems with
in an organizational extranet allows the organization to selectively open only part of its internetwork to the Internet. The figure
"A Phalanx of Firewalls"
shows a simple example of how nesting firewalls can produce two security zones -- one for internal, proprietary systems and the other for open, shared extranet systems.
In general, as you move inward into an internetwork across firewalls, the level of security should be constant or increase, not decrease. In other words, the inner firewalls should be stronger than the outer ones. When stronger firewalls are used for the outermost perimeter, intruders able to pierce that perimeter will almost certainly be able to easily bypass internal firewalls. On the other hand, when firewalls increase in strength as they move inward to more valuable resources, intruders face greater obstacles to access as they attempt to attack those resources.
By properly nesting firewalls and combining them with virtual private networks (VPNs), it's
possible to partition intranets into security zones within the extranet. Internal peer networks and intranets can maintain interconnectivity within security zones while restricting access to outsiders (see the figure
"Mixing and Matching"
).
No security infrastructure can reliably and securely operate by itself. Until true AI -- capable of making reasoned decisions affecting all extranet users -- is developed, an experienced human should be included in the decision loop. Network auditing is a requirement, however, to allow automated systems to monitor all extranet access, flag any suspicious activity, and then notify the human network manager appropriately.
Weighing Caution Against Performance
The extranet manager is responsible for determining what to audit, what to record, and what type of event should trigger a notification (and what type of notification the event deserves, such as e-mail, a wireless page, or a weekly status report). Being too cautious can be costl
y in time wasted on false alarms, hardware required to store excessively detailed audit data, and time spent on keeping track of all the audit information. On the other hand, a lack of caution can allow intruders to slip in unnoticed.
Deciding how to audit extranet access and what to audit are important decisions that should be made with the informed participation of all responsible parties -- and probably a security consultant. As with any other aspect of extranet security, all parties should be aware of the cost of implementation and the risk related to forgoing the security feature. The final decision should balance both.
Securing Open Channels
The TCP/IP protocol suite is a set of open standards designed for interoperability. This openness can pose a security risk because TCP/IP data is generally transmitted in the clear, often across public networks, and usually across networks about which the source and destination systems have no knowledge.
The remainder of this article intro
duces some of the security and encryption protocols that are currently implemented or in development for use at the application, transport, and network layers.
Application-Layer Security
Virtually any application that requires a password for access could be said to provide some degree of application-layer security, but fewer applications actually use that password to secure the data that's passed back and forth between client and server. This section introduces some of the more popular applications that implement security of this type at the application layer.
Secure Electronic Transaction
MasterCard International and Visa International, after a great deal of work and some apparent disagreement, released a specification for the Secure Electronic Transaction (SET) protocol in 1996. Developed with input from GTE, IBM, Microsoft, Netscape, SAIC, Terisa, and Verisign, and eventually supported by American Express and other credit-card issuers, the SET protocol defines how transaction
data flows among card users, merchants, and banks; it also defines the security functions (i.e., digital signatures, hashes, and encryption) that must support these transactions.
Major card issuers have been urging their cardholders not to use their cards for Internet transactions unless they also use SET. (Some issuers have also supported the CyberCash service.) Most organizations providing Internet-commerce services and software have committed to supporting SET when it's completely specified, with widespread deployment of SET-enabled commerce applications likely to occur by the end of this year.
Secure HTTP
The Hypertext Transfer Protocol (HTTP), upon which the Web is built, does not include any mechanisms for security. The Secure HTTP (S-HTTP) protocol was developed as an extension to HTTP and is documented in Internet Engineering Task Force (IETF) working group documents.
S-HTTP described a mechanism for using standard cryptographic tools to encrypt HTTP data transfers. Although
S-HTTP was widely implemented in Web-server software by 1995, few browsers that implemented this protocol were available. The popularity of Netscape's secure browser and server offerings has largely eclipsed S-HTTP.
Pretty Good Privacy
Pretty Good Privacy (PGP) is not, strictly speaking, a network application. PGP is a program that can be used to create and verify digital signatures and to encrypt, decrypt, and compress data.
It's widely used to encrypt, decrypt, sign, or verify data that has been or is about to be transmitted across an open network, and it has gained considerable popularity. The PGP file formats are described in RFC 1991, and PGP has often been grafted onto other network applications to provide security.
Secure MIME
MIME, which stands for Multipurpose Internet Mail Extensions, is documented in RFC 1521. It defines an orderly method of attaching files for transmission over the Internet. The Secure MIME (S/MIME) specification adds a hierarchical approach to
security, providing a formal definition of users and certifiers and making it more scalable to large organizations.
MIME Object Security Services
Another approach to security with MIME is described in RFC 1848. MIME Object Security Services (MOSS) describes how encryption and digital signatures can be added to MIME objects.
CyberCash
The CyberCash Internet commerce application protocol, described in RFC 1898, has been used since 1995 to process credit-card transactions on the Internet. This protocol is notable because it's implemented at the application layer, encrypting and digitally signing credit-card transaction data so that consumers are notified of their transaction approval (or denial) and merchants are able to complete the transaction within seconds.
Transactions are encrypted from the consumer to the card processor, and all transactions and approvals are digitally signed. The CyberCash protocol is similar to the SET specification.
Transport Layer Security
With no widely accepted secure protocol for Web commerce, and with few prospects for early completion of the S-HTTP project, Netscape seized on the opportunity and developed its own security protocol, which the company deployed widely in freely distributed browsers as well as in a line of commercial Web servers. Later released for use in standards development, the Secure Sockets Layer (SSL) operated between the transport layer and the application layer, offering a protocol for negotiating a secure connection between client and server.
By using the transport layer, SSL can encrypt the application data stream between any application clients and servers, not just Web clients and servers, as long as they interface properly with TCP through SSL. Although SSL and its apparent failings have received a lot of attention, most of the deficiencies have been related either to problems with the way in which SSL was implemented or to the length of the keys used. To date, SSL continues to be a reasonable -- and
widely implemented -- mechanism for encrypting streams of data from applications.
Network Layer Security
The IETF formed the IP Security Protocol working group (
IPSEC
) to develop methods to protect IP client protocols at the network layer. As of early 1997, the group's efforts had produced IP Header Authentication (HA, described in RFC 1826) and the IP Encapsulating Security Protocol (ESP, described in RFC 1827).
Some other protocols described by this working group are Simple Key Management for Internet Protocols (SKIP), Internet Security Association and Key Management Protocol (ISAKMP), and Internet Key Management Protocol (IKMP). These are described in draft documents available from the IETF Web site.
Where to Find
Bellcore
Piscataway, NJ
Phone: 908-699-5800 ext. 11
Internet:
http://www.bellcore.com/SECURITY/skeywp.html
Defending from the Unthinkable
