Network Working Group R. Braden Request for Comments: 1636 ISI Category: Informational D. Clark MIT Laboratory for Computer Science S. Crocker Trusted Information Systems, Inc. C. Huitema INRIA, IAB Chair June 1994 Report of IAB Workshop on Security in the Internet Architecture February 8-10, 1994 Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract This document is a report on an Internet architecture workshop, initiated by the IAB and held at USC Information Sciences Institute on February 8-10, 1994. This workshop generally focused on security issues in the Internet architecture. This document should be regarded as a set of working notes containing ideas about security that were developed by Internet experts in a broad spectrum of areas, including routing, mobility, realtime service, and provider requirements, as well as security. It contains some significant diversity of opinions on some important issues. This memo is offered as one input in the process of developing viable security mechanisms and procedures for the Internet. Braden, Clark, Crocker & Huitema [Page 1] RFC 1636 IAB Workshop Report June 1994 Table of Contents 1. INTRODUCTION .................................................. 2 2. OVERVIEW ...................................................... 4 2.1 Strategic and Political Issues ........................... 4 2.2 Security Issues .......................................... 4 2.3 DNS Names for Certificates ............................... 7 3. FIREWALL ARCHITECTURE ......................................... 9 3.1 Introduction ............................................. 9 3.2 Application-Layer Firewalls .............................. 11 3.3 IP-Layer Firewalls ....................................... 12 4. SECURE QOS FORWARDING ......................................... 21 4.1 The Requirement for Setup ................................ 21 4.2 Securing the Setup Process. .............................. 22 4.3 Validating an LLID ....................................... 24 4.4 Dynamics of Setup ........................................ 28 4.5 Receiver-Initiated Setup ................................. 30 4.6 Other Issues ............................................. 30 5. AN AUTHENTICATION SERVICE ..................................... 35 5.1 Names and Credentials .................................... 36 5.2 Identity-Based Authorization ............................. 37 5.3 Choosing Credentials ..................................... 38 6. OTHER ISSUES .................................................. 39 6.1 Privacy and Authentication of Multicast Groups ........... 39 6.2 Secure Plug-and-Play a Must .............................. 41 6.3 A Short-Term Confidentiality Mechanism ................... 42 7. CONCLUSIONS ................................................... 44 7.1 Suggested Short-Term Actions ............................. 44 7.2 Suggested Medium-Term Actions ............................ 46 7.3 Suggested Long-Term Actions .............................. 46 APPENDIX A -- Workshop Organization .............................. 48 Security Considerations .......................................... 52 Authors' Addresses ............................................... 52 1. INTRODUCTION The Internet Architecture Board (IAB) holds occasional workshops designed to consider long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture. This long-term planning function of the IAB is complementary to the ongoing engineering efforts performed by working groups of the Internet Engineering Task Force (IETF), under the leadership of the Internet Engineering Steering Group (IESG) and area directorates. An IAB-initiated workshop on the role of security in the Internet Architecture was held on February 8-10, 1994 at the Information Sciences Institute of the University of Southern California, in Braden, Clark, Crocker & Huitema [Page 2] RFC 1636 IAB Workshop Report June 1994 Marina del Rey, California. This RFC reports the results of the workshop. In addition to the IAB members, attendees at this meeting included the IESG Area Directors for the relevant areas (Internet, Transport, Security, and IPng) and a group of 15 other experts in the following areas: IPng, routing, mobility, realtime service, and security (see Appendix for a list of attendees). The IAB explicitly tried to balance the number of attendees from each area of expertise. Logistics limited the attendance to about 30, which unfortunately meant that many highly qualified experts were omitted from the invitation list. In summary, the objectives of this workshop were (1) to explore the interconnections between security and the rest of the Internet architecture, and (2) to develop recommendations for the Internet community on future directions with respect to security. These objectives arose from a conviction in the IAB that the two most important problem areas for the Internet architecture are scaling and security. While the scaling problems have led to a flood of activities on IPng, there has been less effort devoted to security. Although some came to the workshop eager to discuss short-term security issues in the Internet, the workshop program was designed to focus more on long-term issues and broad principles. Thus, the meeting began with the following ground rule: valid topics of discussion should involve both security and at least one from the list: (a) routing (unicast and multicast), (b) mobility, and (c) realtime service. As a basis for initial discussion, the invitees met via email to generate a set of scenarios (see Appendix) satisfying this ground rule. The 30 attendees were divided into three "breakout" groups, with each group including experts in all the areas. The meeting was then structured as plenary meetings alternating with parallel breakout group sessions (see the agenda in Appendix). On the third day, the groups produced text summarizing the results of their discussions. This memo is composed of that text, somewhat rearranged and edited into a single document. The meeting process determined the character of this document. It should be regarded as a set of working notes produced by mostly- autonomous groups, containing some diversity of opinions as well as duplication of ideas. It is not the output of the "security community", but instead represents ideas about security developed by a broad spectrum of Internet experts. It is offered as a step in a process of developing viable security mechanisms and procedures for the Internet. Braden, Clark, Crocker & Huitema [Page 3] RFC 1636 IAB Workshop Report June 1994 2. OVERVIEW 2.1 Strategic and Political Issues Despite the workshop emphasis on architectural issues, there was considerable discussion of the real-politik of security. For a number of years, the IETF, with IAB backing, has worked on developing PEM, which provides email security with a great deal of functionality. A question was repeatedly raised at the workshop: why has user acceptance of PEM been slow? A number of answers to this question were suggested. (a) High-quality implementations have been slow in coming. (b) The use of a patented technology, the RSA algorithm, violates social conventions of the Internet. (c) Export restrictions dampen vendor enthusiasm. (d) PEM currently depends upon a certificate hierarchy for its names, and certificates form a new and complex name space. There is no organizational infrastructure in place for creat- ing and managing this name space. (e) There is no directory infrastructure available for looking up certificates. The decision to use X.500 has been a complete failure, due to the slow deployment of X.500 in the Internet. Because of UDP packet size restrictions, it is not currently feasible to store certificates in the DNS, even if the DNS were expanded to hold records for individual email users. It seems probable that more than one, and possibly all, of these reasons are at work to discourage PEM adoption. The baleful comment about eating: "Everything I enjoy is either immoral, illegal, or fattening" seems to apply to the cryptography technology that is required for Internet security. 2.2 Security Issues Almost everyone agrees that the Internet needs more and better security. However, that may mean different things to different people. Four top-level requirements for Internet security were identified: end-to-end security, end-system security, secure QOS, and secure network infrastructure. Braden, Clark, Crocker & Huitema [Page 4] RFC 1636 IAB Workshop Report June 1994 A. End-to-End Security One requirement is to support confidentiality, authentication and integrity for end-to-end communications. These security services are best provided on an end-to-end basis, in order to minimize the number of network components that users must trust. Here the "end" may be the end system itself, or a proxy (e.g., a firewall) acting on behalf of an end system. For point-to-point applications, the workshop felt that existing security techniques are well suited to support confidentiality, authentication and integrity services efficiently. These existing techniques include symmetric encryption applied on an end-to-end basis, message digest functions, and key management algorithms. Current work in these areas in the IETF include the PEM and Common Authentication Technologies working groups. The group favored a strategic direction for coping with export restrictions: separate authentication from privacy (i.e., confidentiality). This will allow work to proceed on authentication for the Internet, despite government restrictions on export of privacy technology. Conversely, it will allow easy deployment of privacy without authentication, where this is appropriate. The workshop explored the implications of multicasting for end-to-end security. Some of the unicast security techniques can be applied directly to multicast applications, while others must be modified. Section 6.2 contains the results of these discussions; in summary, the conclusions were: a) Existing technology is adequate to support confidentiality, authentication, and integrity at the level of an entire multicast group. Supporting authentication and integrity at the level of an individual multicast source is performance-limited and will require technology advances. b) End-to-end controls should be based on end system or user identifiers, not low level identifiers or locator information. This requirement should spawn engineering work which consists of applying known key distribution Braden, Clark, Crocker & Huitema [Page 5] RFC 1636 IAB Workshop Report June 1994 and cryptographic techniques. B. End-System Security Every host has its own security defenses, but the strength of these defenses depends upon the care that is taken in administering them. Careful host security administration means plugging security holes in the kernel and applications as well as enforcing discipline on users to set good (hard to crack) passwords. Good security administration is labor-intensive, and therefore organizations often find it difficult to maintain the security of a large number of internal machines. To protect their machines from outside subversion, organizations often erect an outer security wall or "perimeter". Machines inside the perimeter communicate with the rest of the Internet only through a small set of carefully managed machines called "firewalls". Firewalls may operate at the application layer, in which case they are application relays, or at the IP layer, in which case they are firewall routers. The workshop spent considerable time on the architecture of firewall routers. The results are contained in Section 3. C. Secure QOS The Internet is being extended to provide quality-of-service capabilities; this is the topic called "realtime service" in the workshop. These extensions raise a new set of security issues for the architecture, to assure that users are not allowed to attach to resources they are not authorized to use, both to prevent theft of resources and to prevent denial of service due to unauthorized traffic. The resources to be protected include link shares, service classes or queues, multicast trees, and so on. These resources are used as virtual channels within the network, where each virtual channel is intended to be used by a particular subset or "class" of packets. Secure QOS, i.e., protection against improper virtual channel usage, is a form of access control mechanism. In general it will be based on some form of state establishment (setup) that defines authorized "classes". This setup may be done via management configuration (typically in advance and for aggregates of users), or it may be done dynamically via control information in packets or special messages (typically at the time of use by the source or receiver(s) of the Braden, Clark, Crocker & Huitema [Page 6] RFC 1636 IAB Workshop Report June 1994 flow/data). In addition to state establishment, some form of authentication will be needed to assure that successive packets belong to the established class. The general case to be solved is the multicast group, since in general the multicast problem includes the two-party case as a subset. The workshop developed an approach to the secure QOS problem, which appears in Section 4 below. D. Secure Network Infrastructure Network operation depends upon the management and control protocols used to configure and operate the network infrastructure, including routers and DNS servers. An attack on the network infrastructure may cause denial-of-service from the user viewpoint, but from the network operators' viewpoint, security from attack requires authentication and integrity for network control and management messages. Securing the routing protocols seems to be a straightforward engineering task. The workshop concluded the following. a) All routing information exchanges should be authenticated between neighboring routers. b) The sources of all route information should be authenticated. c) Although authenticating the authority of an injector of route information is feasible, authentication of operations on that routing information (e.g., aggregation) requires further consideration. Securing router management protocols (e.g., SNMP, Telnet, TFTP) is urgent, because of the currently active threats. Fortunately, the design task should be a straightforward application of existing authentication mechanisms. Securing DNS is an important issue, but it did not receive much attention at the workshop. 2.3 DNS Names for Certificates As noted in Section 2.1, work on PEM has assumed the use of X.509 distinguished names as the basis for issuing certificates, with public-key encryption. The most controversial discussion at the workshop concerned the possibility of using DNS (i.e., domain) names instead of X.509 distinguished names as (at least) an interim basis for Internet security. Braden, Clark, Crocker & Huitema [Page 7] RFC 1636 IAB Workshop Report June 1994 The argument in favor of DNS names is that they are simple and well understood in the Internet world. It is easy for a computer operating in the Internet to be identified this way, and users who receive email on such machines already have DNS mailbox names. In contrast, introducing X.509 distinguished names for security will add a new layer of names. Most importantly, there is an existing administrative model for assigning DNS names. There is no administrative infrastructure for assigning X.509 distinguished names, and generating them may be too complex for early acceptance. The advocates of DNS names for certificates hope that using DNS names would encourage the widespread use of security in the Internet. It is expected that DNS names can be replaced later by a more capable naming mechanism such as X.509-based certificates. The basic argument against DNS names as a basis for security is that they are too "weak". Their use may lead to confusion in many instances, and this confusion can only grow as more organizations and individuals attach to the Internet. Some commercial email systems employ numeric mailbox names, and in many organizations there are uncertainties such as whether "bumber@foo.edu" belongs to Bill Umber or Tom Bumber. While it is feasible to make DNS names more descriptive, there is a concern that the existing infrastructure, with millions of short, non-descriptive names, will be an impediment to adoption of more descriptive names. It was noted that the question of what name space to use for certificates is independent of the problem of building an infrastructure for retrieving those names. Because of UDP packet size restrictions, it would not be feasible to store certificates in the DNS without significant changes, even if the DNS were expanded to hold records for individual email users. The group was unable to reach a consensus on the issue of using DNS names for security; further discussion in the Internet community is needed. Braden, Clark, Crocker & Huitema [Page 8] RFC 1636 IAB Workshop Report June 1994 3. FIREWALL ARCHITECTURE 3.1 Introduction A firewall may be used to isolate a specific connected segment of Internet topology. When such a segment has multiple links to the rest of the Internet, coordinated firewall machines are required on all the links. Firewalls may be implemented at different layers in the protocol stack. They are most commonly implemented at the application layer by forwarding (application) gateways, or at the IP (Internet) layer by filtering routers. Section 3.2 discusses application gateways. Section 3.3 concerns Internet-layer firewalls, which filter IP datagrams entering or leaving a security perimeter. The general architectural model for a firewall should separate policy, i.e., determining whether or not the requester of a service should be granted access to that service, from control, i.e., limiting access to resources to those who have been granted access. 3.1.1 The Use for Firewalls Firewalls are a very emotional topic in the Internet community. Some community members feel the firewall concept is very powerful because firewalls aggregate security functions in a single place, simplifying management, installation and configuration. Others feel that firewalls are damaging for the same reason: they provide "a hard, crunchy outside with a soft chewy center", i.e., firewalls foster a false sense of security, leading to lax security within the firewall perimeter. They observe that much of the "computer crime" in corporate environments is perpetrated by insiders, immune to the perimeter defense strategy. Firewall advocates counter that firewalls are important as an additional safeguard; they should not be regarded as a substitute for careful security management within the perimeter. Firewall detractors are also concerned about the difficulty of using firewalls, requiring multiple logins and other out-of-band mechanisms, and their interference with the usability and vitality of the Internet. However, firewalls are a fact of life in the Internet today. They have been constructed for pragmatic reasons by organizations interested in a higher level of security than may be possible without them. This section will try to outline some of the advantages and disadvantages of firewalls, and some Braden, Clark, Crocker & Huitema [Page 9] RFC 1636 IAB Workshop Report June 1994 instances where they are useful. Consider a large organization of thousands of hosts. If every host is allowed to communicate directly with the outside world, attackers will attempt to penetrate the organization by finding the weakest host in the organization, breaching its defenses, and then using the resources of that host to extend the penetration further within the organization. In some sense, firewalls are not so much a solution to a security problem as they are a reaction to a more basic software engineering/administration problem: configuring a large number of host systems for good security. If this more basic problem could be solved, firewalls would generally be unnecessary. It is interesting to consider the effect that implementing a firewall has upon various individuals in the organization. Consider first the effect upon an organization's most secure host. This host basically receives little or no extra protection, because its own perimeter defenses are as strong or stronger than the firewall. In addition, the firewall will probably reduce the connectivity available to this host, as well as the reliability of the communications path to the outside world, resulting in inconvenience to the user(s) of this host. From this (most secure) user's point of view, the firewall is a loss. On the other hand, a host with poor security can "hide" behind the firewall. In exchange for a more limited ability to communicate with the outside world, this host can benefit from the higher level of security provided by the firewall, which is assumed to be based upon the best security available in the entire organization. If this host only wants to communicate with other hosts inside the organization, the outside communications limitations imposed by the firewall may not even be noticed. From this host's viewpoint, better security has been gained at little or no cost. Finally, consider the point of view of the organization as a whole. A firewall allows the extension of the best security in the organization across the whole organization. This is a benefit (except in the case where all host perimeter defenses in the organization are equal). Centralized access control also becomes possible, which may be either a benefit or a cost, depending upon the organization. The "secure" hosts within the organization may perceive a loss, while the "unsecure" hosts receive a benefit. The cost/benefit ratio to the organization as a whole thus depends upon the relative numbers of "secure" and "unsecure" hosts in the organization. Braden, Clark, Crocker & Huitema [Page 10] RFC 1636 IAB Workshop Report June 1994 Consider some cases where firewalls do not make sense. An individual can be thought of as an organization of one host. The security of all the host(s) is thus (trivially) identical, and by definition the best available to the organization. In this case the choice of firewall is simple. Does this individual wish to communicate with the outside or not? If not, then the "perfect" firewall is implemented (by complete disconnection). If yes, then the host perimeter will be the same as the firewall perimeter, so a firewall becomes unnecessary. Another interesting case is an organization that consists of individuals with few shared interests. This might be the case of a service provider that sells public access to the network. An unrelated community of subscribers should probably be considered as individuals, rather than an organization. Firewalls for the whole organization may make little sense in this case. To summarize, the benefit of a firewall depends upon the nature of the organization it protects. A firewall can be used to extend the best available protection within the organization across the entire organization, and thus be of benefit to large organizations with large numbers of poorly administered hosts. A firewall may produce little or no perceived benefit, however, to the individuals within an organization who have strong host perimeters already. 3.2 Application-Layer Firewalls An application-layer firewall can be represented by the following diagram. C <---> F <---> S Here the requesting client C opens its transport connection to the firewall F rather than directly to the desired server S. One mechanism for redirecting C's request to F's IP address rather than S's could be based on the DNS. When C attempts to resolve S's name, its DNS lookup would return a "service redirection" record (analogous to an MX record) for S. The service redirection record would return the IP address of F. C enters some authentication conversation to identify itself to F, and specifies its intention to request a specific service from S. F then decides if C is authorized to invoke this service. If C is authorized, F initiates a transport layer connection to S and begins the operation, passing requests and responses between C and Braden, Clark, Crocker & Huitema [Page 11] RFC 1636 IAB Workshop Report June 1994 S. A major advantage of this scenario over an IP-layer firewall is that raw IP datagrams are never passed through the firewall. Because the firewall operates at the application layer, it has the opportunity to handle and verify all data passing through it, and it may be more secure against illicit rendezvous attacks (see below). Application layer firewalls also have important disadvantages. For full benefit, an application level firewall must be coded specifically for each application. This severely limits the deployment of new applications. The firewall also represents a new point of failure; if it ceases to be reachable, the application fails. Application layer firewalls also may affect performance more than IP-layer firewalls, depending on specific mechanisms in use. 3.3 IP-Layer Firewalls Our model of an IP-layer firewall is a multi-ported IP router that applies a set of rules to each incoming IP datagram, to decide whether it will be forwarded. It is said to "filter" IP datagrams, based on information available in the packet headers. A firewall router generally has a set of filtering rules, each of which specifies a "packet profile" and an "action". The packet profile specifies values for particular header fields, e.g., source and destination IP address, protocol number, and other suitable source and destination identifying information (for instance, port numbers). The set of possible information that may be used to match packets is called an "association". The exact nature of an association is an open issue. The high-speed datagram forwarding path in the firewall processes every arriving packet against all the packet profiles of all active rules, and when a profile matches, it applies the corresponding action. Typical actions may include forwarding, dropping, sending a failure response, or logging for exception tracking. There may be a default rule for use when no other rule matches, which would probably specify a drop action. In addition to the packet profile, some firewalls may also use some cryptographic information to authenticate the packet, as described below in section 3.3.2. Braden, Clark, Crocker & Huitema [Page 12] RFC 1636 IAB Workshop Report June 1994 3.3.1 Policy Control Level This section presents a model for the control of a firewall router, with some examples of specific mechanisms that might be used. 1. A client C attempts to access a service S. (Client here can mean either a person or a process - that also is an issue to be resolved.) 2. The initiation of access to that service may result in an attempt to cross one or more boundaries of protection via firewall router(s). 3. The policy control level sets filters in the firewall router(s), to permit or deny that attempt. The policy control level consists of two distinct functions, authentication and authorization. Authentication is the function of verifying the claimed identity of a user. The authentication function should be distributed across the Internet, so that a user in one organization can be authenticated to another organization. Once a user is authenticated, it is then the job of the authorization service local to the resource being requested to determine if that user is authorized to access that resource. If authorization is granted, the filter in the firewall can be updated to permit that access. As an aid to understanding the issues, we introduce a particular detailed mechanism. We emphasize that this mechanism is intended only as an illustrative example; actual engineering of the mechanism will no doubt lead to many changes. Our mechanism is illustrated by the following sketch. Here a user wishes to connect from a computer C behind firewall F1, to a server S behind firewall F2. A1 is a particular authentication server and Z1 is a particular authorization server. C <-------> F1 <-------> F2 <-------> S \ / \_____ / \ \ / A1 Z1 C attempts to initiate its conversation by sending an initial packet to S. C uses a normal DNS lookup to resolve S's name, and uses normal IP routing mechanisms. C's packet reaches Braden, Clark, Crocker & Huitema [Page 13] RFC 1636 IAB Workshop Report June 1994 firewall router F1, which rejects the packet because it does not match any acceptable packet profile. F1 returns an "Authentication Required" error indication to C, including a list of authentication/authorization servers that F1 trusts. This indication might be a new type of ICMP Destination Unreachable packet, or some other mechanism for communicating with C. When C receives the error indication, authenticates itself with A1, one of the authentication servers listed in the error indication, after validating A1's identity. C then requests authorization from server Z1 (using a ticket provided by A1), informs Z1 of the application it wishes to perform, and provides a profile for the packets it wishes to pass through F1. Z1 then performs an authorization function to decide whether to allow C to penetrate F1. If C is to be allowed, Z1 then informs the firewall F1 to allow packets matching the packet profile to pass through the firewall F1. After C's packets penetrate F1, they may again be rejected by a second firewall F2. C could perform the same procedures with authentication server A2 and authorization server Z2, which F2 trusts. This is illustrated by the following schematic diagram of the sequence of events. Braden, Clark, Crocker & Huitema [Page 14] RFC 1636 IAB Workshop Report June 1994 ----------+--------+--------+------------+------------+---- | C | A1 | Z1 | F1 | F2 | S ----------+--------+--------+------------+------------+---- | Sends pkt| | | | | | to S ----------------------->Intercept;| | | | | | requires | | | | | |authenticat'n | | <------------------------------- | | |Auth'cate | | | | | | C to A1 ----> | | | | | |Provide | | | | | <------- ticket| | | | | Request | | | | | |authoriz'n| | | | | | -------------------> Is C| | | | | |allowed?| | | | | | OK ---------> | | |Resend | | | Set filter | | | first pkt| | | | | | to S -------------------------->(OK)------>Intercept;| | | | | | requires | | | | | |authenticat'n | <------------------------------------------- | | (Repeat | | | | | |procedure | | | | | with A2,Z2)| | | | | | ... | | | | | |Resend | | | | | | first pkt| | | | | | ------------------------------>(OK)--------(OK)------> | | | | | | -----------+--------+--------+------------+------------+---- Again, we emphasize that this is only intended as a partial sketch of one possible mechanism. It omits some significant issues, including the possibility of asymmetric routes (see 3.3.3 below), and the possibility that the profiles may be different in the two directions between C and S. We could imagine generalizing this to an arbitrary sequence of firewalls. However, security requires that each of the firewalls be able to verify that data packets actually come from C. This packet authentication problem, which is discussed in the next section, could be extremely difficult if the data must traverse more than one or possibly two firewalls in sequence. Braden, Clark, Crocker & Huitema [Page 15] RFC 1636 IAB Workshop Report June 1994 A firewall router may require re-authentication because: * it has been added to the path by a routing change, or * it has timed out the profile entry, or * it has been newly re-activated, perhaps after a crash that lost its list of acceptable profiles. If C contacts authentication and authorization servers that S trusts, C may utilize tickets given it by these servers when initiating its use of S, and avoid re-authenticating itself to S. Although the authentication server A1 and the authorization server Z1 are conceptually separate, they may run on the same computer or router or even be separate aspects of a single program. The protocol that C speaks to an An, the protocol that C speaks to a Zn, and the protocol that Zn speaks to Fn are not specified in these notes. The authentication mechanism used with An and the packet profile required by a firewall Fn are considered matters of policy. 3.3.2 Source Authentication We next consider how to protect against spoofing the IP source address, i.e., injecting packets that are alleged from come from C but do not. There are three classes of mechanisms to prevent such spoofing of IP-level firewalls. The mechanisms outlined here are also discussed in Section 4.3 below. o Packet Profile Only The lowest level of security consists of allowing the IP- layer firewall to filter packets purely on the basis of the packet profile. This is essentially the approach used by filtering routers today, with the addition of (1) authentication and authorization servers to control the filtering profiles, and (2) the automatic "Authentication Required" notification mechanism. This approach provides almost no security; it does not prevent other computers from spoofing packets that appear to be transmitted by C, or from taking over C's transport level connection to S. o Sealed Packets In the second level of security, each packet is "sealed" with a secure hash algorithm. An authentication server Ai Braden, Clark, Crocker & Huitema [Page 16] RFC 1636 IAB Workshop Report June 1994 chooses a secret and shares it with the source host S and also with the authorization server Zi, which shares the secret with the firewall Fi. Every packet that C transmits contains a hash value that depends upon both the contents of the packet and the secret value. The firewall Fi can compute the same hash function and verify that the packet was originated by a computer that knew the shared secret. This approach does raise issues of how much C trusts Zi and Fi. Since they know C's secret, Zi or Fi could spoof C. If C does not trust all Z's and F's in its path, a stronger mechanism (see below) is needed. A more difficult problem arises in authenticating C's packets when more than one firewall lies in the path. Carrying a separate seal for each firewall that is penetrated would be costly in terms of packet size. On the other hand, in order to use a single seal, all the firewalls would have to cooperate, and this might require a much more complex mechanism than the one sketched in the previous section. Morever, it may require mutual trust among all of the authentication servers Ai and authorization servers Zi; any of these servers could undermine all the others. Another possibility to be investigated is to use hop-by-hop rather than end-to-end authentication of C's packets. That is, each firewall would substitute into the packet the hash needed by the next firewall. Multi-firewall source authentication is a difficult problem that needs more investigation. o Packet Signatures In the third level of security, each packet is "signed" using a public/private key algorithm. C shares its public key with Zn, which shares it with Fn. In this scenario, C can safely use one pair of keys for all authorization servers and firewalls. No authorization server or firewall can spoof C because they cannot sign packets correctly. Although packet signing gives a much higher level of security, it requires public key algorithms that are patented and currently very expensive to compute; their time must be added to that for the hash algorithm. Also, signing the hash generally makes it larger. Braden, Clark, Crocker & Huitema [Page 17] RFC 1636 IAB Workshop Report June 1994 3.3.3 Other Firewall Issues o Performance An Internet-layer firewall has the advantage of generality and flexibility. However, filtering introduces a potential performance problem. Performance may depend upon the number and position of the packet fields used for filtering, and upon the number of rules against which a packet has to be matched. Denial of service attacks require that the per-packet rule matching and the drop path be able to keep up with the interface speed. o Multicasting To allow multicast traffic to penetrate a firewall, the rule that is needed should be supplied by the receiver rather than the sender. However, this will not work with the challenge mechanism outlined in Section 3.3.1, since "Authentication Required" notifications would be sent to the sender, not to the receiver(s). Multicast conversations may use any of the three levels of security described in the previous section, but all firewalls will have to share the same secret with the originator of the data stream. That secret would have to be provided to the receivers through other channels and then passed to the firewalls at the receivers' initiative (in much the same way that resources are reserved at receiver's initiative in RSVP). o Asymmetric Routing Given a client computer C utilizing a service from another computer C through a firewall F: if the packets returning from S to C take a different route than packets from C to S, they may encounter another firewall F' which has not been authorized to pass packets from S to C (unlike F, which has been). F' will challenge S rather than C, but S may not have credentials to authenticate itself with a server trusted by F'. Fortunately, this asymmetric routing situation is not a problem for the common case of single homed administrative domains, where any asymmetric routes converge at the firewall. Braden, Clark, Crocker & Huitema [Page 18] RFC 1636 IAB Workshop Report June 1994 o Illicit Rendezvous None of these mechanisms prevent two users on opposite sides of a firewall from rendezvousing with a custom application written over a protocol that may have been authorized to run through a firewall. For example, if an organization has a policy that certain information is sensitive and must not be allowed outside its premises, a firewall will not be enough to enforce this policy if users are able to attach sensitive information to mail and send it outside to arbitrary parties. Similarly, a firewall will not prevent all problems with incoming data. If users import programs and execute them, the programs may have Trojan horses which disclose sensitive information or modify or delete important data. Executable code comes in many, many forms, including PostScript files, scripts for various interpreters, and even return addresses for sendmail. A firewall can detect some of these and scan for some forms of potentially hazardous code, but it cannot stop users from transforming things that look like "data" into programs. We consider these problems to be somewhat outside the scope of the firewall router mechanism. It is a matter of the policies implemented by the organization owning the firewalls to address these issues. o Transparency for Security Packets For the mechanisms described above to operate, the "Authentication Required" notification and the authentication/authorization protocol that is used between the client computer and the authentication and authorization servers trusted by a firewall, must be passed by all firewalls automatically. This might be on the basis of the packet profiles involved in security. Alternatively, firewall routers might serve as application-layer firewalls for these types of communications. They could then validate the data they pass to avoid spoofing or illicit rendezvous. 3.3.4 Firewall-Friendly Applications Firewall routers have problems with certain communication patterns where requests are initiated by the server, including callbacks and multiple connections (e.g., FTP). It was Braden, Clark, Crocker & Huitema [Page 19] RFC 1636 IAB Workshop Report June 1994 suggested that it would be useful to have guidelines to application designers to help them to build 'firewall-friendly applications'. The following guidelines were suggested: 1) no inbound calls (the xterm problem), 2) fixed port numbers (no portmapper or tcpmux), 3) integral redirection is good (application gateways), 4) no redirection in the protocol, 5) 32 bit sequence numbers that are crypto-strong random #'s, and 6) fixed length and number of header fields. Type fields are good, but they may not be needed if there are fixed port numbers. 3.3.5 Conclusions Compared to an application-layer firewall, an IP-layer firewall scheme could provide a number of benefits: - No extra authentication is required for end hosts. - A single authentication protocol can be used for all intended applications. - An IP-layer firewall causes less performance degradation. - An IP-layer firewall may be able to crash and recover state without disturbing open TCP connections. - Routes can shift without disturbing open TCP connections. - There is no single point of failure. - It is independent of application. However, there are substantial difficult design issues to be solved, particularly in the areas of multiple firewalls, assymmetric routes, multicasting, and performance. Braden, Clark, Crocker & Huitema [Page 20] RFC 1636 IAB Workshop Report June 1994 4. SECURE QOS FORWARDING When the Internet supports special qualities-of-service (QOS) for particular packet flows, there will be a new set of security problems. There will be a need to authenticate and authorize users asking for those QOS values that are expensive in network resources, and it will be necessary to prevent theft of these resources and denial-of-service attacks by others. This section contains a conceptual model for these problems, which we may call secure QOS forwarding. The issues here differ from end-to-end security and firewalls, because QOS forwarding security may need to be enforced at every router along a path. It was noted that this is not a new problem; it was stated and solved in a theoretical way in a thesis by Radia Perlman. 4.1 The Requirement for Setup Setup is an essential part of any QOS mechanism. However, it may be argued that there are also good engineering reasons for setup in any Internet-layer security mechanism, even without QOS support. In the abstract, one could imagine a pure datagram model in which each IP packet separately carried the necessary authorizations for all the stages in the forwarding path. Realistically, this is not practical, since the security information may be both unacceptably large and computationally demanding for inclusion in every packet. This seems to imply the need for some form of state setup for security. Thus, we presume a two stage process that moves somewhat away from the pure datagram model. In the first stage, the setup stage, some state is established in the routers (and other network elements) that describes how a subsequent stream of packets is to be treated. In the second stage, the classification stage, the arriving packets are matched with the correct state information and processed. The terminology in use today calls these different state descriptions "classes", and the process of sorting "classification". Setup can take many forms. It could be dynamic, invoked across the network by an application as described above. The setup process could also be the manual configuration of a router by means of a protocol such as SNMP or remote login. For example, a network link, such as a link across the Atlantic, might be shared by a number of users who purchase it jointly. They might implement this sharing by configuring a router with specifications, or filters, which describe the sorts of packets that are permitted to use each share. Whether the setup is Braden, Clark, Crocker & Huitema [Page 21] RFC 1636 IAB Workshop Report June 1994 dynamic or manual, short-lived or semi-permanent, it has the same effect: it creates packet classes in the router and defines how packets are to be classified as they arrive. Much of the current research on extensions to IP for QOS, such as realtime service, has assumed an explicit setup phase and a classification stage. The setup stage is accomplished using protocols such as RSVP or ST-II, which also specify how the subsequent classification is to be done. Security at the setup stage would thus simply be an extension to such a protocol. It should be noted that there are alternative proposals for realtime QOS, based on an implicit setup process. 4.2 Securing the Setup Process. To secure the setup process, we require that a setup request be accompanied by user credentials that provide a trustworthy assurance that the requester is known and is authorized to make the request in question. We refer to the credentials used in the setup phase as the high-level identification (HLID). A simple version of this authorization would be a password on the management interface to a router (the limitations of such a password scheme are well known and not the issue here). In the case of setup requests made by individual applications, some user-specific authorization must be assumed. While there could be any number of ways to organize the HLIDs, the objective of scaling suggests that a global framework for user naming and authentication would be useful. The choice of naming framework is discussed further in Section 5. Note that this discussion, which concerns controlling access to network resources and security devices, is distinct from end-to-end authentication and access control; however, the same authentication infrastructure could be used for both. In general, while significant engineering effort will be required to define a setup architecture for the Internet, there is no need to develop new security techniques. However, for the security aspects of the classification process, there are significant problems related to performance and cost. We thus focus on that aspect of the overall framework in more detail. Above, we defined the high-level ID (HLID) as that set of information presented as part of a setup request. There may also be a "low-level ID" (LLID), sometimes called a "cookie", carried in each packet to drive classification. In current proposals for IP extensions for QOS, packets are classified based on existing Braden, Clark, Crocker & Huitema [Page 22] RFC 1636 IAB Workshop Report June 1994 packet fields, e.g., source and destination addresses, ports, and protocol type. It is important to note that the LLID is distinct from the address of the user, at least conceptually. By stressing this distinction we make the point that the privileges of the user are not determined by the address in use. If the user's address changes, the privileges do not. The LLID in a packet acts as a form of tag that is used by some or all routers along a path to make decisions about the sort of QOS that shall be granted to this packet. An LLID might refer to a data stream between a single source-destination address pair, or it might be more general and encompass a range of data streams. There is no requirement that the LLID embody a syntax that permits a router to discern the QOS parameters that it represents, but there also is no prohibition against imposing such a structure. We propose that an IP datagram contain one LLID, which can be used at various stages of the network to map the packet to a class. We reject the alternative that the packet should have a variable number of LLIDs, each one for a different point in the net. Again, this is not just a security comment, but it has security implications. The attributes of the LLID should be picked to match as broad a range of requirements as possible. * Its duration (discussed below) must match both the needs of the security protocol, balancing robustness and efficiency, and the needs of the application, which will have to deal with renewal of the setup when the LLID expires. A useful end-node facility would be a service to renew setup requests automatically. * The degree of trust must be high enough to meet the most stringent requirement we can reasonably meet. * The granularity of the LLID structure must permit packet classification into classes fine-grained enough for any resource selection in the network. We should therefore expect that each separate stream of packets from an application will have a distinct LLID. There will be little opportunity for aggregating multiple streams under one LLID or one authenticator. Braden, Clark, Crocker & Huitema [Page 23] RFC 1636 IAB Workshop Report June 1994 4.3 Validating an LLID At a minimum, it is necessary to validate the use of an LLID in context, i.e., to ensure that it is being asserted in an authorized fashion. Unauthorized use of an LLID could result in theft of service or denial-of-service attacks, where packets not emitted by an authorized sender are accorded the QOS treatment reserved for that sender (or for a group of which the sender is a member). Thus, use of an LLID should be authenticated by routers that make QOS decisions based on that LLID. (Note that not all routers may "pay attention" to the LLID.) In principle, the validity of an LLID assertion needs to be checked on every packet, though not necessarily at every router; it may be possible to restrict the checks to security perimeters. At those routers that must validate LLIDs, there is an obvious concern over the performance impact. Therefore, a router may adopt a less rigorous approach to LLID validation. For example, a router may elect to sample a data stream and validate some, but not all, packets. It may also elect to forward packets first and perform selective validation as a background activity. In the least stringent approach, a router might log selected packets and validate them as part of an audit activity much later. There are several candidate techniques for validating the use of LLIDs. We have identified three basic techniques, which differ in terms of computational performance, bandwidth overhead, and effectiveness (resistance to various forms of attack). * Digital Signatures The first technique entails the use of public key cryptography and digital signatures. The sender of each packet signs the packet (header and payload) by computing a one-way hash over the packet and transforming the hash value using a private key associated with the LLID. The resulting authenticator value is included in the packet header. The binding between the public key and the LLID is established through a connection setup procedure that might make use of public keys that enjoy a much longer lifetime. Using public key technology yields the advantage that any router can validate a packet, but no router is entrusted with data that would enable it to generate a packet with a valid authenticator (i.e., which would be viewed as valid by other routers.) This characteristic makes this technique ideal from the standpoint of the "principle of least privilege." Braden, Clark, Crocker & Huitema [Page 24] RFC 1636 IAB Workshop Report June 1994 Public key cryptosystems such as RSA have the advantage that validation of a signature is much faster than signing, which reduces the router processing burden. Nonetheless, this approach is not likely to be feasible for anything other than selective checking by routers, given current public key algorithm performance. * Sealing The next technique is based on the use of the same type of one-way hash function used for digital signatures, but it does not require signing the hash value. Here the sender computes a one-way hash with a secret quantity (essentially a "key") appended to the packet. This process is an example of what is sometimes referred to more generically as cryptographic "sealing." The inclusion of this key at the end of the hash computation results in a hash value that is not predictable by any entity not possessing the key. The resulting hash value is the authenticator and is included in the packet header. A router validates a packet by recomputing the hash value over the received packet with the same secret quantity appended. If the transmitted hash value matches the recomputed hash value, the packet is declared valid. Unlike the signature technique, sealing implies that all routers capable of verifying a seal are also capable of generating (forging) a seal. Thus, this technique requires that the sender trust the routers not to misuse the key. This technique has been described in terms of a single secret key shared between the sender and all the routers that need to validate packets associated with an LLID. A related alternative strategy uses the same authenticator technique, but shares the secret key on a pairwise basis, e.g., between the sender and the first router, between the first router and the next, etc. This avoids the need to distribute the secret key among a large group of routers, but it requires that the setup mechanism enable Router A to convince his neighbor (Router B) that Router A is authorized to represent traffic on a specific LLID or set of LLIDs. This might best be done by encapsulating the packet inside a wrapper that both ends of the link can validate. Once this strategy is in place, it may even be most efficient for routers to aggregate traffic between them, providing authentication not on a per-LLID basis, since the router pairs are prepared to "trust" one another to accurately represent the data stream LLIDs. For a unicast data stream, the use of pairwise keying between routers does not represent a real change in the trust Braden, Clark, Crocker & Huitema