RFCs in HTML Format

RFC 1636

                       Report of IAB Workshop on

                 Security in the Internet Architecture

                          February 8-10, 1994

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
RFC 1636 IAB Workshop Report June 1994 The existence of "multiple names" for a person may or may not imply the existence of an "equivalence" relation. It may be useful to know that <huitema@sophia.inria.fr> and <huitema@iab.isoc.org> are two names for the same person, but there are many cases where the user does not want to make all his tokens visible. 5.3 Choosing Credentials Let's consider again the example of Christian Huitema accessing a file at CNRI. He will have to interact with INRIA's outgoing firewall and with CNRI's incoming controls. Regardless of whether authorization depends upon capabilities or upon multiple association names, a different credential may be needed in each firewall on the path. For example, assuming multiple names are used, he will use an INRIA name, <huitema@sophia.inria.fr>, to be authorized by INRIA to use network resources, and he will use an IAB name, <huitema@iab.isoc.org>, to access the file server. Thus comes an obvious problem: how does he choose the credential appropriate to a particular firewall? More precisely, how does the computer program that manages the connection discover that it should use one credential in response to INRIA's firewall challenge and another in response to CNRI's request? There are many possible answers. The program could simply pass all the user's credentials and let the remote machine pick one. This works, but poses some efficiency problems: passing all possible names is bulky, looking through many names is long. Advertising many names is also very undesirable for privacy and security reasons: one does not want remote servers to collect statistics on all the credentials that a particular user may have. Another possibility is to let the agent that requests an authorization pass the set of credentials that it is willing to accept, e.g., "I am ready to serve CNRI employees and IAB members". This poses the same privacy and security problems as the previous solutions, although to a lesser degree. In fact, the problem of choosing a name is the same as the generic "trust path" model. The name to choose is merely a path in the authentication graph, and network specialists are expected to know how to find paths in graphs. In the short term, it is probably possible to use a "default name" or "principal name", at least for local transactions, and to count on the user to "guess" the credential that is required by remote services. To leave the local environment we need only the local credentials; to contact a remote server we need only the destination credentials. So we need one or maybe two credentials, Braden, Clark, Crocker & Huitema [Page 38]
RFC 1636 IAB Workshop Report June 1994 which may be derived from the destination. It will be very often the case that the generic credential is enough; then wildcards; then "FTP provided" tokens. 6. OTHER ISSUES 6.1 Privacy and Authentication of Multicast Groups Multicast applications are becoming an increasingly important part of Internet communications. Packet voice, video and shared whiteboard can be powerful productivity tools for users. For these applications to have maximum value to their users, a variety of security services will be required. Existing techniques are directly applicable to providing privacy for a private teleconference. If each member of the conference shares a single key for a symmetric encryption algorithm (such as DES), existing point-to-point security techniques can be extended to protect communication within the group from outsiders. However, slight modifications to existing techniques are required to accommodate the multicast environment. Each packet will require independent cryptographic processing to ensure that packets from multiple sources can be independently decrypted by the numerous receivers, particularly in the presence of lost packets. N-party authentication and key management will be required to establish the shared key among the proper group members. This can be done by extending existing two-party key management techniques pairwise. For example, the conference manager may provide the key to each member following individual authentication; for example, this could be implemented trivially using PEM technology. The overhead experienced by each host computer in the conference will be similar to that of existing point-to-point encryption applications, This overhead is be low enough that, today, software encryption can offer adequate performance to secure whiteboard and voice traffic, while hardware encryption is adequate for video. The nature of multicast communication adds an additional requirement. Existing multicast conferences provide gradual degradation in quality as the packet loss rate increases. To be acceptable, authentication protocols must tolerate lost packets. Techniques to accomplish this efficiently need to be developed. One initial sketch is outlined below. Engineering work will be required to validate the practicality of this approach. Braden, Clark, Crocker & Huitema [Page 39]
RFC 1636 IAB Workshop Report June 1994 The use of symmetric encryption provides the members of the conference with effective protection from outsiders. However, because all members of the conference share a single key, it does not provide a means of authenticating individual conference members. In principle, existing techniques, based on one-way hash functions coupled with digital signatures based on asymmetric encryption algorithms, can provide individual authentication. One-way hash functions such as MD5 are comparable in cost to symmetric encryption. However, digital signatures are considerably more costly, both in computation and in communication size. The degree of overhead depends on the quality of authentication required. In summary, realtime authentication at the granularity of group membership is easy and cheap, but individual authentication is costly in time and space. Over time, the costs of both communications and processing are expected to decline. It is possible that this will help make authentication at the level of individual conference participants. There are two conflicting trends: (1) increasing CPU speeds to provide symmetric encryption, and (2) increasing communication data rates. If both technologies increase proportionally, there will be no net gain, at least if the grain size is measured in terms of bits, rather than as a period in seconds. The group felt that the correct approach to end-to-end controls is the use of encryption, as discussed above. The alternative is to control the ability of a user to join a multicast group as a listener, or as a speaker. However, we are not comfortable with the level of assurance that we can offer if we attempt to ensure end-to-end semantics using these means. Any passive penetration of the network, i.e., any wire-tap, can compromise the privacy of the transmitted information. We must acknowledge, however, that problems with deployment of encryption code and hardware, and especially problems of export controls, will create a pressure to use the tools described in Section 4 to implement a form of end- to-end control. Such a decision would raise no new issues in security technology. The shared key now used for encrypting the data could instead be used as the basis for authenticating a multicast group join request. This would require modification of the multicast packet format, but nothing more. Our concern is not the technical difficulty of this approach, but the level of assurance we can offer the user. Braden, Clark, Crocker & Huitema [Page 40]
RFC 1636 IAB Workshop Report June 1994 6.2 Secure Plug-and-Play a Must Plug-and-play is the ability to plug a new device into a network and have it obtain the information it needs to communicate with other devices, without requiring any new configuration information. Secure plug-and-play is an important Internet requirement, and a central architectural issue is whether it can be made to scale well. For plug-and-play operation, a new machine that is "plugged" into the network needs to: (1) Obtain an locator so it can communicate with other devices (2) Register or obtain a name to be identified by (e.g., machine name) (3) Discover services available on the network (e.g., printers, routers, file servers, etc.) (4) Discover other systems on the network so it can communicate with them. In some environments, no security mechanisms are required because physical security and local knowledge of the users are sufficient protection. At the other end of the spectrum is a large network with many groups of users, different types of outside connections, and levels of administrative control. In such environments, similar plug-and-play capabilities are needed, but the new device must be "authenticated" before it can perform these functions. In each step in the discovery process the new device must authenticate itself prior to learning about services. The steps might be: - Obtain a HLID from a smart card, smart disk, or similar device. - Authenticate itself with the first plug-and-play server using its HLID, to register a name and to find the location of other services. - Discover services available on the network (e.g., printers, routers, file servers, etc.) based on its HLID. - Discover other systems on the network so it can communicate with them. Braden, Clark, Crocker & Huitema [Page 41]
RFC 1636 IAB Workshop Report June 1994 The problem of taking a system out of the box and initially configuring it is similar to the problem of a mobile or portable machine that a human wants to connect to a local network temporarily in order to receive services on that network. How can the local network authenticate the human (and therefore the human's machine) and know which services this visiting machine is permitted to use? The human must be endowed with a high level identifier (HLID) which acts as his/her passport and can be verified by the local network. This high level identifier must be globally unique and registered/assigned by some recognized authority. When the human plugs the machine onto a local net, the machine identifies itself to the net with the human's high level identifier. If local net has a policy of permitting anyone to plug and play on its network, it will ignore the HLID and assign an address (locator), permitting the visitor unrestricted access and privileges. More likely, the local net will authenticate the HLID prior to granting the visitor an address or any privileges. At this point, the HLID has only authenticated the visitor to the local network; the issue of which services or resources the visitor is entitled to use has not been addressed. It is desirable to develop a low-overhead approach to granting authentications to new users. This will help in the case of visitors to a site, as well as new users joining a facility. 6.3 A Short-Term Confidentiality Mechanism Authentication has customarily been achieved using passwords. In the absence of active attacks, the greatest threat to computer system security may be the ease with which passwords can be "snooped" by the promiscuous monitoring of shared-media networks. There are known security techniques for achieving authentication without exposing passwords to interception, for example the techniques implemented in the well-known Kerberos system. However, authentication systems such as Kerberos currently operate only in isolation within organizational boundaries. Developing and deploying a global authentication infrastructure is an important objective, but it will take some years. Another useful approach in the short term is the use of a challenge-response user authentication scheme (e.g., S/Key). One of the groups explored another interim approach to guarding passwords: introducing a readily-used confidentiality mechanism based on an encrypted TCP connection. This would operate at the IP level to encrypt the IP payload, including the TCP header, to Braden, Clark, Crocker & Huitema [Page 42]
RFC 1636 IAB Workshop Report June 1994 allow the nature as well of the contents of the communication to be kept private. It could be implemented to provide either "strict" protection (the connection fails if the other side cannot decrypt your data stream) or "loose" protection (falling back to non-private TCP if decryption fails). Loose protection would allow interoperability with older hosts in a seamless (non-user-intrusive) manner. One-time keys may be exchanged during the SYN handshake that starts the TCP connection. Using one-time keys avoids a need for infrastructure support and does not require trust between the organizations on the two ends of the connection. Tieing the key exchange to the SYN handshake will avoid the possibility of having the connection fully open without knowing the state of encryption on both ends of the connection. Although it may still be theoretically possible to intercept the SYN exchange and subvert the connection by an active "man-in-the-middle" attack, in practice such attacks on TCP connections are quite difficult unless the routing protocols have been subverted. The keys could be exchanged using a new option that specifies the key exchange protocol, the data encryption algorithm, and the key to be used to decrypt the connection. It could be possible to include multiple options in the same SYN segment, specifying different encryption models; the far end would then need to acknowledge the option that it is willing to use. In this case, the lack of an acknowledgement would imply disinterest in decrypting the datastream. If a loose privacy policy were in force, the connection could continue even without an acknowledgment. The policy, "strict" or "loose", would be set by either the user or the default configuration for the machine. One must however observe that a TCP option can carry only a limited amount of data. Efficient protection against crypto- analysis of the Diffie-Hellmann scheme may require the use of a very long modulus, e.g., 1024 bits, which cannot be carried in the 40 bytes available for TCP options. One would thus have either to define an "extended option" format or to implement encryption in a separate protocol layered between TCP and IP, perhaps using a version of "IP security". The detailed engineering of such a solution would have to be studied by a working group. A TCP connection encryption mechanism such as that just outlined requires no application changes, although it does require kernel changes. It has important drawbacks, including failure to provide privacy for privacy for UDP, and the great likelihood of export control restrictions. If Diffie-Hellman were used, there would Braden, Clark, Crocker & Huitema [Page 43]
RFC 1636 IAB Workshop Report June 1994 also be patent issues. 7. CONCLUSIONS As a practical matter, security must be added to the Internet incrementally. For example, a scheme that requires, as a precondition for any improvement, changes to application code, the DNS, routers and firewalls all at once will be very hard to deploy. One of the reasons the workshop explored schemes that are local to the IP layer is that we surmise that they might be easier to deploy in practice. There are two competing observations that must shape planning for Internet security. One is the well known expression: "the best is the enemy of the good." The other is the observation that the attacks are getting better. Finally, it should noted that the principle of least privilege, which was mentioned above, may be in contradiction to the principle of least cost. 7.1 Suggested Short-Term Actions The general recommendation for short-term Internet security policy was that the IETF should make a list of desirable short-term actions and then reach out to work with other organizations to carry them out. Other organizations include regionals, which may be in a good position to provide site security counseling services to their customers, vendors and other providers, and other societies. We should also give input to the US government to influence their posture on security in the direction desired by the community. A suggested preliminary list of short-term actions was developed. o Perform external diagnostic security probes Organizations should be encouraged to use CRACK and other tools to check the robustness of their own passwords. It would also be useful to run a variety of security probes from outside. Since this is a very sensitive issue, some care needs to be taken to get the proper auspices for such probing. Braden, Clark, Crocker & Huitema [Page 44]
RFC 1636 IAB Workshop Report June 1994 Useful probe tools include: ISS: Klaus (GA) SATAN: Farmer Venema ICEPICK: NRL o Determine Security-Risk Publication Channels What channels should be used for disseminating information of security risks? o Encourage use of one-time passwords. Available packages: S/Key, SecurID, Enigma, Digital Pathways. o Develop and publish guidelines for protocol developers, for security-friendliness and firewall-friendliness. o Control topology to isolate threats o Set privacy policy: * Always * As much as possible o Bring Site Security Handbook up to date o Support use of Kerberos The subject of the "Clipper chip" came up several times, but there was not sufficient discussion of this very complex issue for this grouip to reach a recommendation. It has been observed that there are a number of quite differing viewpoints about Clipper. o Some people accept the government's Clipper proposal, including key escrow by the US government and the requirement that encryption be in hardware. o Some people don't mind key escrow by the government in principle, but the object to the hardware requirement. o Some people don't mind key escrow in principle, but don't want the government to hold the keys. They would be comfortable with having the organization which owns the data hold the keys. o Some people don't want key escrow at all. Braden, Clark, Crocker & Huitema [Page 45]
RFC 1636 IAB Workshop Report June 1994 o Some people don't mind the hardware or the key escrow, but they don't think this will be acceptable to other countries and thus will not work internationally. This report takes no position on any of these viewpoints. 7.2 Suggested Medium-Term Actions These actions require some protocol design or modification; however, they use existing security technology and require no research. o Authentication Protocol There is a problem of the choice of technology. Public key technology is generally deemed superior, but it is patented and can also induce relatively long computations. Symmetric key technology (Needham-Schroeder algorithm, as used in Kerberos) has some technical drawbacks but it is not patented. A system based on symmetric keys and used only for authentication would be freely exportable without being subject to patents. o Push Kerberos Engineering is needed on Kerberos to allow it to interoperate with mechanisms that use public key cryptography. o Push PEM/RIPEM/PGP... o Develop an authenticated DNS o Develop a key management mechanism o Set up a certificate server infrastructure Possible server mechanisms include the DNS, Finger, SNMP, Email, Web, and FTP. o Engineer authentication for the Web 7.3 Suggested Long-Term Actions In this category, we have situations where a threat has been identified and solutions are imaginable, but closure has not been reached on the principles. Braden, Clark, Crocker & Huitema [Page 46]
RFC 1636 IAB Workshop Report June 1994 o Executable Apps o Router sabotage counter-measures o Prevent Byzantine routing. o Proxy Computing o Decomposition of computers o Are there "good" viruses? Braden, Clark, Crocker & Huitema [Page 47]
RFC 1636 IAB Workshop Report June 1994 APPENDIX A -- Workshop Organization The following list of attendees indicates also the breakout group to which they were assigned. Breakout Groups Group I.1 Leader: 1 Christian Huitema, INRIA (IAB) 1 Steve Bellovin, AT&T 1 Bob Braden, ISI (IAB) 1 John Curran, NEARNET 1 Phill Gross, ANS (IETF/IAB) 1 Stev Knowles, FTP Software (Internet AD) 1 Barry Leiner, USRA (IAB) 1 Paul Mockapetris, ISI 1 Yakov Rekhter, IBM (IAB) 1 Dave Sincoskie, Bellcore (IAB) Group I.2 Leader: 2 Steve Crocker, TIS (Security AD) 2 Jon Crowcroft 2 Steve Deering, PARC 2 Paul Francis, NTT 2 Van Jacobson, LBL 2 Phil Karn, Qualcomm 2 Allison Mankin, NRL (Transport AD, IPng AD) 2 Radia Perlman, Novell 2 John Romkey, ELF (IAB) 2 Mike StJohns, ARPA (IAB) Group I.3 Leader: 3 Dave Clark, MIT 3 Deborah Estrin, USC 3 Elise Gerich, Merit (IAB) 3 Steve Kent, BBN (IAB) 3 Tony Lauck, DEC (IAB) 3 Tony Li, CISCO 3 Bob Hinden, Sun (IESG->IAB liaison, Routing AD) 3 Jun Murai, WIDE (IAB) 3 Scott Shenker, PARC 3 Abel Weinrib, Bellcore The following were able to attend only the third day, due to a conflicting ISOC Board of Trustees meeting: Braden, Clark, Crocker & Huitema [Page 48]
RFC 1636 IAB Workshop Report June 1994 Scott Bradner, Harvard (IPng AD) Jon Postel, ISI (IAB) The workshop agenda was as follows. Tues Feb 8 9:00 - 10:30 Plenary Discuss facilities, meeting goals, agenda, organization. Establish some minimal common understandings. Assign scenarios to Breakout I groups. 10:30 - 13:00 Breakout I meetings Each breakout group examine one or more scenarios and formulate a list of design questions. Lunch available on 11th floor. 13:00 - 15:00 Plenary Report, discuss. Collate and shorten list of design issues. Organize Breakout II groups to work on these issues. 15:00 - 17:30 Breakout IIa meetings Work on design issues. Wed Feb 9 9:00 - 10:00 Plenary Report, discuss. 10:00 - 13:30 Breakout IIb meetings More work on design questions, develop list of requirements. 13:30 - 14:30 Plenary Report, discuss. 15:30 - 17:30 Breakout III groups Thurs Feb 10 9:00 - 9:30 Plenary 9:30 - 11:00 Breakout Groups (wrapup) 11:00 - 12:00 Plenary Discuss possible short-term security recommendations 13:00 - 14:00 Plenary -- Discuss short-term security issues 14:00 - 14:30 Plenary -- Presentation by Steve Bellovin Braden, Clark, Crocker & Huitema [Page 49]
RFC 1636 IAB Workshop Report June 1994 14:30 - 16:00 Plenary -- Long- and Medium-term Recommendations The following scenarios were used as a starting point for discussions. It distinguished security-S (security as a service to the end systems) from security-M, security as a mechanism to support other services. The workshop was intended to be primarily concerned with interactions among the following different *services*: o Security-S o Routing o Multi-destination delivery (mcast-S) o Realtime Packet scheduling (realtime) o Mobility o Accounting (and maybe large-scale?) These categories were then applied to the following scenarios: S1. Support a private teleconference among mobile hosts connected to the Internet. [Security-S, mcast-S, realtime, mobility] S2. The group in S1 is 1/3 the Internet, i.e., there are VERY severe scaling problems. [Security-S, mcast-S, realtime, mobility, large-scale] S3. Charge for communication to support a video teleconference. [Accounting, realtime, mcast-S] S4. I am travelling with my laptop. I tune in to radio channel IP- RADIO, pick-up the beacon and start using it. Who gets the bill? Why do they believe this is me? Is "me" a piece of hardware (IP address) or a certified user (PEM certificate)? [Mobility, accounting (, realtime, mcast-S)] S5. A Politically Important Person will mcast an Internet presentation, without danger of interruptions from the audience. S6. The travel industry wants to use Internet to deliver tickets to customer premises directly in a secure way, but the customer has only dial-up capability. [Security-S, mobility] Braden, Clark, Crocker & Huitema [Page 50]
RFC 1636 IAB Workshop Report June 1994 S7. I am traveling with my laptop and this friendly host is running the autoconfiguration protocol. I immediately get an address as "mac1.friendly.host.com". (What is the difference between my laptop and a bona fide autoconfigured local station?) [Security-S, mobility] S8. Multiple people are connected to a subnetwork providing mobility (e.g., cellular, packet radio). The subnetwork is connected to multiple places in the "fixed" backbone. How can routing be done efficiently? [Routing, mobility] The following scenarios that were suggested do not fit into the primary thrust of the workshop, generally because they are single- issue topics. Most of them are pure security topics and are concerned with the security perimeter. The last two do not fit into our classification system at all. S9. XYZ corporation has two major branches on opposite ends of the world, and they want to communicate securely over the Internet, with each branch having IP-level connectivity to the other (not through application gateways). S10. I am visiting XYZ corporation, with my laptop. I want to connect it to their LAN to read my email remotely over the Internet. Even though I am inside their corporate firewall, they want to be protect their machines from me. S11. XYZ corporation is trying to use the Internet to support both private and public networking. It wants to provide full connectivity internally between all of its resources, and to provide public access to certain resources (analogous of anonymous ftp servers) S12. The travel industry wants to use Internet to deliver tickets to customer premises directly in a secure way. S13. Some hacker is deliberately subverting routing protocols, including mobile and multicast routing. Design counter measures. S14. Part of the Internet is running IPv4 and part is running IPng (i.e. the Internet is in transition). How can we assure continued secure operation through such a transition? S15. A corporation uses ATM to connect a number of its sites. It also uses Internet. It wants to make use of the ATM as its primary carrier, but also wants to utilize other networking technologies as appropriate (e.g., mobile radio). It wants to support all Braden, Clark, Crocker & Huitema [Page 51]
RFC 1636 IAB Workshop Report June 1994 media (data, voice, video). Security Considerations This memo is entirely concerned with security issues. Authors' Addresses Bob Braden [Editor] USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6695 Phone: (310) 822-1511 EMail: Braden@ISI.EDU

Back to RFC index





Register domain name and transfer | Cheap webhosting service | Domain name registration