RFC 1636

Report of IAB Workshop on Security in the Internet Architecture - February 8-10, 1994

📅 published June 1994, from ietf

Report of IAB Workshop on Security in the Internet Architecture 🎀

Bestie, here's the header rundown 💅

RFC 1636, Network Working Group ✨
Title: Report of IAB Workshop on Security in the Internet Architecture
Workshop dates: February 8-10, 1994 🗓️
Authors: R. Braden (ISI), D. Clark (MIT Laboratory for Computer Science), S. Crocker (Trusted Information Systems, Inc.), and C. Huitema (INRIA, IAB Chair) 👑
Category: Informational 🦋
Date: June 1994 🌸
Obsoletes / Updates: the title block doesn't list anything for either one 🙈

Status of this Memo

okay so this memo is just here to share info with the Internet community 🫶 it is NOT a standard of any kind, and you can spread it around as much as you want because distribution is unlimited 💖

Abstract

so this doc is a report on an Internet architecture workshop 🧚 the IAB started it and it happened at USC Information Sciences Institute on February 8-10, 1994, and the big focus was security in the Internet architecture 🔥

it's giving "working notes" energy. the ideas came from Internet experts across a bunch of areas: routing, mobility, realtime service, provider requirements, and security too 🌈 there's some real disagreement in here on some important stuff, and that's on purpose 🙈 this memo is one input into figuring out viable security mechanisms and procedures for the Internet, not the final word ✨

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 ✨

okay so the Internet Architecture Board (IAB) runs workshops every now and then 🧠 they're for long-term issues and big-picture strategy for the Internet, and they're meant to suggest where the Internet architecture should head next 🔮 this long-term planning is the IAB's job, and it works alongside the engineering the IETF working groups do every day, which runs under the IESG and the area directorates 💜

so the IAB started a workshop on the role of security in the Internet Architecture 🔐 it ran February 8-10, 1994 at the Information Sciences Institute of the University of Southern California in Marina del Rey, California, and this RFC is where the results live 🌴

the IAB members came, obviously 👑 and so did the IESG Area Directors for the relevant areas (Internet, Transport, Security, and IPng) plus a group of 15 other experts in IPng, routing, mobility, realtime service, and security (the Appendix has the full attendee list) 🫶 the IAB really tried to balance how many people came from each area of expertise 💖 logistics capped things at about 30 people, which sadly meant a lot of super qualified experts didn't make the invite list 😭

so the objectives were pretty simple: (1) explore how security connects to the rest of the Internet architecture, and (2) come up with recommendations for the Internet community about where security should go next 🦋 the IAB felt strongly that the two most important problem areas for the Internet architecture are scaling and security 🔥 the scaling side got a flood of IPng activity, but security hasn't gotten nearly as much effort, and that's the gap this workshop was trying to fill 🎀

some people showed up hyped to talk about short-term security stuff, but the program was built to focus on long-term issues and broad principles instead 🧚 so the meeting started with one ground rule: a valid topic has to involve security AND at least one of these: (a) routing (unicast and multicast), (b) mobility, or (c) realtime service 💅 the invitees emailed each other beforehand to come up with a set of scenarios that followed this rule (see the Appendix) ✨

the 30 attendees got split into three "breakout" groups 🍓 each group had experts from every area, so no one was stuck in a bubble 🫶 the meeting alternated between plenary sessions and parallel breakout group sessions (the agenda is in the Appendix) 🌈 on the third day, the groups wrote up text summarizing what they'd talked about 😭 this memo is that text, rearranged and edited into one document 🎀

the meeting process shaped the whole vibe of this doc, so just know going in that it's a set of working notes from mostly-autonomous groups 💜 it has some diversity of opinion AND some repeated ideas, and that's expected ✨ it's not the output of the "security community" 🙈 it's ideas about security from a broad spectrum of Internet experts, offered as one step in the process of developing viable security mechanisms and procedures for the Internet 🦋

(part 1 of 12)

2. OVERVIEW ✨

2.1. Strategic and Political Issues

Okay so even though the workshop was all about architecture, there was a LOT of talk about the real-politik of security 👀

For a bunch of years, the IETF (with IAB backing) has been working on PEM, which gives email security a whole lot of functionality 💌 But a question kept popping up at the workshop: why has user acceptance of PEM been so slow? 🤔 A few answers 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 creating 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 of these reasons, and possibly all of them, 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 👑

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 includes 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 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, so 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. This protects against both theft of resources and 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 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. 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 🍿

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 💜

3. FIREWALL ARCHITECTURE 🔥

3.1. Introduction

A firewall can be used to fence off one specific connected chunk of Internet topology 🏰. If that chunk has multiple links to the rest of the Internet, coordinated firewall machines are required on all of the links 🫶.

Firewalls can live at different layers of the protocol stack ✨. They're most commonly built at the application layer as forwarding (application) gateways, or at the IP (Internet) layer as filtering routers 🧚. Section 3.2 is all about application gateways 💖, and Section 3.3 covers Internet-layer firewalls, which filter IP datagrams entering or leaving a security perimeter 🔥.

The big-brain architectural model says a firewall should separate policy 🤔 (deciding whether the requester of a service should be granted access to that service) from control 🔒 (limiting access to resources to only the folks who've been granted access).

3.1.1 The Use for Firewalls 💅

Firewalls are a very emotional topic in the Internet community 😭. Some folks think the firewall concept is super powerful, because firewalls aggregate security functions in a single place, which makes management, installation and configuration way simpler 💖. Others think firewalls are damaging for that exact same reason: they give you "a hard, crunchy outside with a soft chewy center" 🍓. In other words, firewalls foster a false sense of security, leading to lax security inside the perimeter 🙈. They point out that a lot of the "computer crime" in corporate environments is perpetrated by insiders, who are totally immune to the perimeter defense strategy 💀.

Firewall advocates counter that firewalls are important as an additional safeguard, and they should not be regarded as a substitute for careful security management within the perimeter 🫶. Firewall detractors are also worried about how hard firewalls are to use, with multiple logins and other out-of-band mechanisms, and about their interference with the usability and vitality of the Internet 🥺.

However, firewalls are a fact of life in the Internet today ✨. They've been constructed for pragmatic reasons by organizations that want 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 instances where they're useful 🌈.

Consider a large organization with thousands of hosts 🏢. If every host is allowed to communicate directly with the outside world, attackers will try to penetrate the organization by finding the weakest host, breaching its defenses, and then using that host's resources to extend the penetration further inside 😱. In some sense, firewalls aren't so much a solution to a security problem as 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's interesting to think about how a firewall affects different people in the organization 👀. First, the organization's most secure host 🛡️. This host basically receives little or no extra protection, because its own perimeter defenses are as strong as or stronger than the firewall. The firewall will probably reduce this host's connectivity, as well as the reliability of its communications path to the outside world, which is an inconvenience for 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 gets the higher level of security the firewall provides, which is assumed to be based upon the best security available in the entire organization 🧁. If this host only wants to talk to other hosts inside the organization, the outside communications limitations may not even be noticed. From this host's viewpoint, better security has been gained at little or no cost 🎀.

Finally, let's look at the organization as a whole 🌍. A firewall allows the best security in the organization to be extended 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 💅. So the cost/benefit ratio to the organization as a whole depends upon the relative numbers of "secure" and "unsecure" hosts in the organization 🧮.

Consider some cases where firewalls don't make sense 🙅. An individual can be thought of as an organization of one host 🧍. The security of all the host(s) is therefore (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, 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, so 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 already have strong host perimeters 🥹.

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 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 🔑.

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 🎯.

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.) 🙋
The initiation of access to that service may result in an attempt to cross one or more boundaries of protection via firewall router(s). 🚧
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 ✅.

Asymmetric Routing 🦋

Okay so picture this, bestie 🫶: a client computer C is using a service from another computer C through a firewall F. If the packets coming back from S to C take a totally different route than the packets going from C to S, they might run into another firewall, F', that was never given permission to pass packets from S to C (unlike F, which totally was 💅). F' will challenge S instead of C, but S might not have any credentials to prove itself to a server that F' trusts 😭

Thankfully, this asymmetric routing thing is not a problem for the common case of single homed administrative domains, where any asymmetric routes converge at the firewall ✨ 🌸

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. Sneaky, right? 🙈

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. Not ideal 💀

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. The plot twist nobody asked for 😭

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. Policy problems need policy solutions, periodt 💅

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. Validation era, let's gooo ✨

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). Those server-initiated vibes are lowkey chaotic 😭 It was 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:

no inbound calls (the xterm problem),
fixed port numbers (no portmapper or tcpmux),
integral redirection is good (application gateways),
no redirection in the protocol,
32 bit sequence numbers that are crypto-strong random #'s, and
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, asymmetric routes, multicasting, and performance. Okay, the homework is real 📚

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. Every. Single. Router. 😭

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 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. Same energy, different vibes ✨

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. Passwords, we know, we know 🙈

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 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. Your address can change, your privileges don't, iconic 👑

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. Main character energy in a single LLID 🦋

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. 🍓🧚

4.3 Validating an LLID 🛡️

Okay, so at a minimum, we need to validate the use of an LLID in context, i.e., make sure it's being asserted in an authorized fashion. 🙅‍♀️ Unauthorized use of an LLID could lead to theft of service or denial-of-service attacks, where packets that weren't emitted by an authorized sender get the QOS treatment reserved for that sender (or for a group the sender belongs to). 😭 So 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's an obvious concern over the performance impact, so 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've identified three basic techniques, which differ in terms of computational performance, bandwidth overhead, and effectiveness (resistance to various forms of attack). Let's go through them! 💅

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 has the advantage that any router can validate a packet, but no router is entrusted with data that would let it generate a packet with a valid authenticator (i.e., one that would be viewed as valid by other routers.) This characteristic makes this technique ideal from the standpoint of the "principle of least privilege." 👑 Public key cryptosystems such as RSA have the advantage that validating 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 same type of one-way hash function used for digital signatures, but it doesn't 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." 🧁 Including this key at the end of the hash computation results in a hash value that isn't predictable by any entity that doesn't possess the key. The resulting hash value is the authenticator, and it's 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 one, 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, and so on. 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 its 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, using pairwise keying between routers doesn't represent a real change in the trust required of the routers or of the setup mechanism, because of the symmetric sharing of the secret key. However, for a multicast connection, this pairwise keying approach is superior, because it prevents a router at one point in a multicast tree from being able to generate traffic that could be inserted at another point in the tree. At worst, a router can generate spurious, but authenticatable, traffic only for routers "below" it in the multicast tree. 🌳

Note that network management fault isolation techniques, e.g., sampling router traffic statistics at different points along a data stream, should permit post hoc detection of packet forgery attacks mounted by rogue routers along a data stream path. Using this technique could provide a deterrent to such activity by routers, which further argues for the pairwise keying approach. 🕵️‍♀️

The sealing technique is faster than the digital signature technique, because the incremental hash calculation (including the appended secret quantity) is much faster than the cryptographic transformation required to sign a hash. ⚡ The processing burden is symmetric here, i.e., the sender and each router devote the same amount of processing power to seal a packet and to verify the seal. Also, a sealed hash may be smaller than a signed hash, even if the same function is used in both cases. (This is because the modulus size of the public key signature algorithm and any ancillary parameters tend to increase the size of the signed hash value.) Moreover, one could use a hash function with a "wide" value and truncate that value, if necessary, to reduce overhead. This option isn't available when the authenticator is a signed hash value. 📏

As a variant on this technique, one could imagine a "clearinghouse" that would receive, from the sender, the secret key used to generate and validate authenticators. A router needing to validate a packet would send a copy of the packet to the clearinghouse, which would check the packet and indicate to the router whether it was a valid packet associated with the LLID in question. Obviously, this variant is viable only if the router is performing infrequent, selective packet validation. However, it does avoid the need to share the authenticator secret among all the routers that must validate packets. 🏦

For both of these techniques, there is a residual vulnerability to denial-of-service attacks based on replay of valid packets during the lifetime of a data stream. Unless packets carry sequence numbers and routers track a sequence number window for each data stream, an (external) attacker can copy valid packets and replay them. 😱 It may be easiest to protect against this form of attack by aggregating all traffic between a pair of routers into a single flow and providing replay protection for the flow as a whole, rather than on a per data stream basis. 🛟

Temporary Passwords

The final technique explored in the workshop takes a very different tack to packet validation. The preceding techniques compute a function of the bits in a packet and transform that value in a fashion that prevents an intruder from generating packets with valid authenticators. The ability to generate packets with valid authenticators for a given LLID requires access to a secret value that is available only to the sender, or to the sender and to the routers participating in a given data stream. 🔒

In contrast, this third technique calls for the authenticator to be a short term, secret quantity that is carried in the packet header, without benefit of further protection. In essence, this technique incorporates a short term "password" into each packet header. 🙈 This approach, like its predecessor, requires that all of the routers validating the LLID be privy to this authenticator. Moreover, the authenticator is visible to any other router or other equipment along the path, and so this technique is much more vulnerable than the previous ones. 💀

Here the same authenticator may be applied to all packets with the same LLID, since the authenticator is not a function of the packet it authenticates. In fact, this suggests that it is feasible to use the LLID as the authenticator. However, adopting this tack would not be consistent with the two previous techniques, each of which requires an explicit, separate authenticator, so we recommend against this optimization. 🙅‍♀️🫶

Okay so this part is where things get spicy 🌶️ because the authenticator stuff has a catch, bestie. Even though the authenticator doesn't depend on the packet's contents, that also makes it super easy to forge packets 😭. If an attacker intercepts the authenticator from any legit packet, they can just copy it onto their own packets and it looks totally real. Not cute. 💀 And if the authenticator can be guessed, they don't even need to wiretap anything to pull it off 🙈. So the authenticator has to be big enough that guessing it is unlikely, and keeping the LLID and the authenticator as separate fields helps with that 🔐.

The big win here is performance 🚀. Checking the authenticator is just a quick comparison, so it's fast. And since it needs to be hard to guess, it doesn't have to take up a lot of room in the packet header 💅.

Now the sequence number idea is lowkey genius ✨. If the routers can see a sequence number, and every stream numbers its packets, then an intruder would have to delete the real packets to sneak in, and that's usually hard to pull off 🦋. Otherwise, the router under attack would spot duplicate sequence numbers and other weird stuff 👀. The tricky part is that real packets can get lost in transit, which leaves gaps in the sequence, so the numbering details would need some serious figuring out 🧩.

We're not getting into collusion here, which is when a user with a valid LLID and authenticator willingly shares them with someone who isn't allowed in 🙅‍♀️. That one should be explored to see if it's actually useful to the bad guy, and whether it's a real threat or just vibes 🤔.

4.4. Dynamics of Setup

Duration of LLID's

The big question with LLIDs is how long they stay valid ⏰. On one end they could last just seconds, which limits the damage if someone steals the authenticator 🧯. On the other end they could be semi-permanent, kinda like credit card numbers 💳. The security techniques we talked about earlier traded some strength for efficiency, and that was fine because the LLID only lived for a short time 💖.

Here's the plus side of long-term LLIDs: you can use simple setup methods, like manually configuring routers to set up packet classes 🛠️. That's going to matter in the short run, because security and dynamic resource allocation protocols probably won't show up at the same time 🕰️.

So the move right now is to design LLIDs as if they're fairly short-lived, but tolerate longer validity in the meantime 🌸. That means we get a workable long-term mechanism in place, even though security is lower at first 😬. Once we have better tools for automatic setup, we can shorten validity periods on an a individual basis, without swapping out any mechanism in the packet forwarding path 🚀✨.

Setup Latency

The Internet has always been about not adding any setup delay between end nodes 🏃‍♀️💨. That's what keeps the classic datagram model quick for fast transactions, and it's a vibe we should keep 🫶.

For setup that happens "in advance", whether it's through a management interface or an end node doing it in the background, latency isn't really a problem ✅. It only becomes an issue for dynamic reservations that are made in response to a specific application request ⚡.

Also, latency is a big deal, but security isn't really what's causing it 🙅‍♀️. The folks designing RSVP and ST-II are already arguing about latency without any security stuff in the mix 🗣️. Adding an authenticator to the request will make validation take more processing, and it might even need a message exchange with an authentication service 📨. Still, it shouldn't drastically change the real time of setup, which might already take about a round-trip delay ⏱️. The authentication and authorization design for the setup protocol just needs to know that setup isn't as demanding as per-packet processing, but it's still kinda time-critical 🕐💅.

One way to handle an expensive setup is to set the request up provisionally and validate it in the background 🎈. That limits the damage from one bad request to a short window of time 🧯. But heads up, bestie: the system is still open to an attack where someone chains together a bunch of setup requests, and each one gives them unauthorized access for at least a short while 😤.

Another thing: someone could flood the setup process with junk requests, and every single one would still need to be processed and rejected 📬. That could stop a legit user from setting up any state at all 😱. Still, flooding attacks leave huge "finger prints" 🔍, so they shouldn't normally be a major threat 🙌. If it does become a problem, you could add something at the setup level that works like "fair queueing" 🚦, which would limit the damage from flooding at the packet level 🛡️.

4.5. Receiver-Initiated Setup

There's recent work on a QOS extension for the Internet, RSVP, where the receiver is the one who reserves resources 🎀. That fits the current IP multicast model, where the receiver has to join the multicast group 🙋‍♀️. The receiver reserves resources so the multicast traffic reaches it with the QOS it wants 💜. In this setup, the receivers' credentials (the HLIDs) are what gets presented during the setup phase 🪪.

Receiver initiation needs an explicit setup phase, no cap 🧠. If setup were implicit and driven by fields already in the packet, there'd be no way to link a packet to a specific receiver, because in multicast the receiver's address never shows up in the packet 🤷‍♀️.

It's also basically impossible to set up "in advance" like this unless the sender and receiver are super tightly coordinated 🤝. Otherwise the receiver wouldn't know ahead of time what LLID is going to be in the packet 🙈. So the receiver can't really set up "semi-permanent" reservations for multicast traffic headed its way 😭. This isn't a security problem, since it exists even without security stuff involved, but the security architecture still has to account for it 🧩✨.

4.6. Other Issues

4.6.1. Encrypting Firewalls and Bypass

Our security vision covers both end node and network protection, and it uses firewalls to split the network into regions with more or less trust 🏰. This is kinda similar to the encrypting-firewall model the military and intelligence world uses, with red (trusted) networks separated from black (untrusted) ones 🔴⚫. The big difference is that in the military version, the partition uses an encryption unit that encrypts as much of the packet as it can for its trip across the black network to another red network 🔐. So the encryption unit's main job, among other things, is to protect data inside the red networks from being disclosed 🫣. Our firewall is more about protecting the trusted (red) part of the network from outside attacks 🛡️. It watches both what comes in and what goes out 👀. And it does allow communication between a node on the trusted side and nodes out in the untrusted parts of the network 🌈.

We'd love to bring our secure QOS model over to those military-style encrypting firewalls 💫. But encryption causes a problem for the secure resource management model we described above, which is based on a two-stage process of setup and classification 😬. The issue is that information has to go from the red region to the black region in the clear 🫠. That includes the setup packets themselves if setup is done dynamically from the end node, and it also includes the classification fields (the LLIDs) in the data packets 📦. You can't encrypt that info when it leaves the red region, because the black network wouldn't be able to read it, and then it couldn't make resource allocation decisions based on it 💀.

To make this control scheme work, the encryption device has to be programmed to let certain packets and packet fields pass through the encryptor in the clear 🔓. Honestly, bypassing encryption like this is considered highly undesirable 🚩. In a high-security situation, the process making the bypass information could get corrupted, and then controlled information could leak out of the secure network by hiding in the bypassed fields of the packets 😱.

Still, we concluded this bypass problem is not insurmountable 🙌. The key idea, like in every bypass case, is to limit the information that passes in the clear, rather than banning it entirely ✨. To keep the bypass info small, you could either do the setup as a management function completely inside the black environment, or split the process into two stages 🪜. In the first stage, which also happens completely in the black context, you define a limited number of setup situations 📋. In the second stage, the red net sends a very small message that picks one request to be instantiated from that pre-defined set 🎯💖.

Okay so the LLID in the packet header is where things get spicy 🌶️. If it's an explicit field (like we've been talking about, but see below 👀), that's a brand new field in every single packet, with maybe as many as 32 bits. Ngl, that's a lot of real estate 💅. The fix has the same energy as before: limit how the field can be used. When the end-node does a setup, it specifies the value of the LLID it wants to use. The red/black encryption unit can observe that, and then limit the components of this field to just the values currently in use ✨. To glow up the situation even more, the encryption unit might be able to aggregate a number of flows onto one flow so they can cross the black net 🦋. That would allow a further reduction in the number of distinct LLIDs that must escape the red region.

The details of this proposal, including some important issues like the time duration of LLIDs in this case, must be considered further 🎀. Still, the initial conclusion that bypass can be built into a general resource control framework is so encouraging 😭. It suggests that both military and commercial forms of security can be built out of the same building blocks. Iconic 👑.

4.6.2. The Principle of Consistent Privilege

A well understood principle of security is the principle of least privilege 🧚. It states that a system is most robust when it is structured to demand the least privilege from its components.

There's a related rule we observe, called the principle of consistent privilege 💜. It's easiest to see with denial of service, where it's especially relevant. For a particular route, no assumption of service can be justified unless we trust the routers to deliver the packets. If a router is corrupted and won't forward packets, the only solution is to find another route that doesn't involve this router 💀. We're not going to get into protocols for finding new routes around a corrupted router here, because that topic is properly part of another topic, securing the network infrastructure. We only observe that either we'll get service from the router or we won't. If the router is corrupted, it doesn't matter how it chooses to attack us. So, as long as the router is part of a forwarding path (most generally a multicast forwarding tree), we shouldn't hesitate to trust it in other ways, like giving it shared resource keys or LLID verifiers 🫶.

This illustrates the principle of consistent privilege 🌸. The principle gets used in the scheme for hop-by-hop or pairwise use of secrets to validate LLIDs in a multicast tree. If a single key is issued for the whole tree, the privilege is not consistent 🙈. We only need to trust a router with respect to the nodes "below" it in the tree. If it fails to forward traffic, it can only affect those nodes. But if we give it the group key, then it can generate bogus traffic and inject it into the tree at any point, affecting traffic for other parts of the tree. If, on the other hand, we use pairwise keys, a corrupt node can only generate bogus traffic with the key for traffic it would directly receive. That's the part of the tree it could damage anyway ✨.

Another requirement we must place on the network concerns routing. If a firewall is in place, we must trust the routing architecture not to bypass that firewall. One way to accomplish this is to eliminate any physical path between the regions other than those that go through the firewall. Operational experience will be required to see whether this simple physical limit is an acceptable constraint 🔥.

4.6.3. Implicit LLID's

We stress the importance of a strong conceptual distinction between the addresses in a packet and the LLID used to classify the packet 💖. The distinction matters a lot, but under limited circumstances it may be possible to overload some of the packet fields and create an LLID from the current packet header. For example, current packet classifiers for IPv4 are not secure, but they seem to work for classifying packets into service classes. They use a number of packet fields together as a form of LLID: the source and destination IP addresses and ports, plus the protocol type 🦋.

This sort of "implicit" LLID must be short-lived, especially if the host can change its IP address as it moves 🏃‍♀️. But if the LLID is established by some sort of dynamic setup protocol, it should be possible to reestablish the LLID as needed 🌈.

The current IPv4 header has no authenticator field to validate the LLID. An authenticator field could be optionally carried in an option, and adding it gives robustness to network reservations 🎀. Any of the schemes described above for creating an authenticator could be used. The exception is that if the simple password-style authenticator is used, it must be an explicit separate field, since the LLID cannot be picked randomly 🙈.

4.6.4. Security without Setup

As we describe this architecture, the setup phase is an essential part of the sequence. This suggests that the current Internet, which has no setup protocols, cannot be secured against denial-of-service attacks 😭. It's important to explore the limits of this point. As we stressed above, setup can occur in many ways. Routers today offer management options to classify packets based on protocol types and other fields found in the header. They use that classification to create a few fair queueing classes that can stop one class from overloading the net to the exclusion of the others 💅.

There are two problem here. The first is that for a setup done using a management interface, the secret shared among the source and the routers to validate the LLID must remain valid for a long time, and it must be manually configured 💀. The second problem is that the granularity of the categories may be coarse. However, it has been proposed, in a thesis by Radia Perlman, that a router might create a separate fair queueing class implicitly for each source address 🧠. This approach uses the addresses as an implicit LLID, and it must have some form of authenticator for robustness. But if the LLID can be trusted, this scheme classifies traffic based only on an implicit setup operation. The granularity of classification isn't enough to provide any QOS distinction. The only objective is to stop the traffic from one source from flooding the net to the exclusion of another 🌊.

4.6.5. Validating Addresses

We make a claim here: if the LLID and the addresses in the packet are conceptually distinct, and there's a suitable means to validate the LLID, then there's no reason to validate the addresses 🫧. For example, a packet constructed with a false source address doesn't seem to represent any security problem, as long as its LLID can be validated 🍓.

An exception to this might possibly lie in communication with mobile hosts. It will require a complete model of threats and requirements in the mobile environment to be sure 🛰️. Still, we make the claim, as a starting point for discussion, that if LLIDs are distinguished from addresses, many of the security concerns with mobility are mitigated and perhaps removed ✨. This point should be validated by more detailed consideration of the mobility problem 🔍.

4.6. Conclusions

a) It is important to conceptually separate a LLID (Low-Level IDentifier) carried in a packet from addresses in the packet 💜.
b) There will be a single LLID carried in each packet. Although this might imply some additional state in the routers compared to using multiple LLIDs, using only one LLID choice is more scalable 🌸.
c) Hop-by-hop LLID authentication mechanisms might provide a highly scalable approach that limits the distribution of secrets. However, the robustness limitations must be investigated thoroughly 🔐.
d) Statistical sampling or after-the-fact detection mechanisms may be employed by routers to address performance concerns 🦋.

5. AN AUTHENTICATION SERVICE 🔐

Okay so the whole job of an authentication service is actually simple: it verifies names, or more precisely, it verifies where a "message" came from ✨. That's different from the authorization service, which decides what services an already-authenticated name is allowed to use 💅. We expect authentication to be an Internet-wide thing, while authorization will be specific to whatever resource is being unlocked 🗝️.

This "identification" function can show up in lots of contexts, like:

One-time passwords: "it is really <huitema@inria.fr> that is responding to this challenge" 🙈
Access to a firewall: "it is really <huitema@inria.fr> that is trying to send data to host-A at port-a" 🧱

There are so many Internet objects we might want to name, e.g.,:

           domain names:   sophia.inria.fr

           machine names:  jupiter.inria.fr

           service names:  www.sophia.inria.fr
                           (in fact, a data base)

           users:          huitema@sophia.inria.fr
           processes:      p112.huitema@sophia.inria.fr
                           p112.sophia.inria.fr

           universal resource locators:
                           http//www.sophia.inria.fr:222/tmp/foobar

Now, you'd think the authentication service only cares about naming humans, since humans are the "responsible" ones and a process gets its access rights because it's acting on behalf of a person 🧑‍💻. But ngl that's way too narrow and kinda misleading 🙅‍♀️. We may have to authenticate "machines" or hardware components too. For example:

When a machine boots, it needs to access resources to configure itself, but it isn't "used" by a person yet, so there's no user 🥺.
On a "distributed processor", component CPUs may need to authenticate each other 🤖.

Machines are different from users, though, because machines can't keep their "secrets" the way people do 🫣. Still, having a simple and extensible name space is a huge win 🏆.

5.1. Names and Credentials

We're making the hypothesis that authorization services will generally use "access control lists" (ACLs), which is basically some definition of a set of authorized users 📋. A compact way to represent that set is to allow "wildcard" authorizations, like "anybody at <Bellcore.com>" or "any machine at <INRIA.FR>" 🃏. The authentication service should be designed to make the authorization service easier to build, and it should support "wildcards" 💜.

BUT wildcards aren't general enough, bestie 😤. If we have a hierarchical name space, a wildcarded entry is limited to that naming hierarchy. For example, a name like <huitema@sophia.inria.fr> could be matched by <*@sophia.inria.fr>, or <*.inria.fr>, or <*.fr>. That's useful as long as you stay at INRIA, but it doesn't solve the generic problem 🙃. Say an IETF file server at CNRI needs to be accessible by all IAB members. Its ACL will just explicitly list the members by name 📝.

The classic approach to naming, like in the X.500 model, is to say that people have "distinguished names" 🎀. Once you've found one of these through some "white pages" service, you can use it as an access key in a global directory service 🔍.

An individual can acquire authorizations from all kinds of sources 🌸. If you're using a pure, identity-based access control system, the user would have to collect multiple identities (aka distinguished names), one for each role they're authorized to access services in 😩. We'll talk about this approach in the next section.

An alternative is for the user to have a very small number of identities, and for the grantors of authorizations to issue (signed) credentials that give the user permissions, linked to her ID 🪪. These extra signed credentials are called "capabilities" ✨. The user can establish her identity with a generic identity credential, like an X.509 certificate, and then establish authorization by presenting capabilities as needed 🫶. It's kinda like getting credit cards linked to the name on your driver's license, then showing the right card plus the license for photo ID 💳.

5.2. Identity-Based Authorization

Let's open the wallet of an average person 👛. We all have a bunch of "credit cards": company cards, actual credit cards, airline frequent flyer memberships, driver's licenses 🛫. Each one is really a token asserting that some relation exists. The bank certifies that checks the bearer presents will be paid, the traffic authorities certify that the bearer has learned how to drive, and so on 🚗. This is an example of identity-based authorization, where one individual gets different names for the different relations they've entered into 🦋.

If we imagine the name space is based on DNS (domain) names, then the person above could be authenticated with names like:

        customer@my-big-bank.com

        customer@frequent-flyer.airline.com

The model here is that "the name is an association" 💖. This fits with name verification procedures, where you build a "chain of trust" between the user and the "resource agent" 🔗. By following a particular path in the trust graph, you can both establish trust and show that the user belongs to an "authorized group" 👑.

Having "multiple names" for one person may or may not imply an "equivalence" relation 🤔. It could be useful to know that <huitema@sophia.inria.fr> and <huitema@iab.isoc.org> are two names for the same person, but there are plenty of cases where the user doesn't want all their tokens visible 🙈🔒.

5.3. Choosing Credentials

Let's revisit the example of Christian Huitema accessing a file at CNRI 📁. He has to interact with INRIA's outgoing firewall and with CNRI's incoming controls 🧱. Whether authorization depends on capabilities or on multiple association names, a different credential might be needed at each firewall on the path 🛡️. For example, if multiple names are used, he'll use an INRIA name, <huitema@sophia.inria.fr>, to get authorized by INRIA to use network resources, and an IAB name, <huitema@iab.isoc.org>, to access the file server 🎯. Which brings up an obvious problem: how does he choose the right credential for a particular firewall? More precisely, how does the computer program managing the connection figure out that it should use one credential when INRIA's firewall challenges it, and a different one when CNRI asks 🤯?

There are lots of possible answers 💭. The program could just pass all the user's credentials and let the remote machine pick one. That works, but it's inefficient: passing every possible name is bulky, and looking through many names takes forever 🐌. Advertising lots of names is also a big no for privacy and security, because nobody wants remote servers collecting statistics on every credential a particular user has 🕵️‍♀️.

Another option is to let the agent requesting authorization pass along the set of credentials it's willing to accept, e.g., "I am ready to serve CNRI employees and IAB members" 🎟️. This has the same privacy and security problems as before, just to a lesser degree 😌. Honestly, choosing a name is the same as the generic "trust path" model. The name to choose is just a path in the authentication graph, and network specialists are expected to know how to find paths in graphs 🧠✨.

In the short term, it's 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 remote services require 🎲. To leave the local environment we only need the local credentials, and to contact a remote server we only need the destination's credentials 📡. So we need one credential, or maybe two, and they may be derived from the destination 🎯. Very often the generic credential will be enough, and after that come wildcards, and then "FTP provided" tokens 🌈.

6. OTHER ISSUES 💅

6.1. Privacy and Authentication of Multicast Groups

Multicast apps are becoming a really big deal in Internet communications 📣. Packet voice, video, and shared whiteboards are seriously powerful productivity tools for users 🎥. For these apps to be as valuable as possible, a bunch of security services will be required 🔐.

Existing techniques work directly for giving privacy to a private teleconference 📞. If every member of the conference shares a single key for a symmetric encryption algorithm (like DES), then existing point-to-point security techniques can be extended to protect communication within the group from outsiders 🫶.

BUT slight modifications to existing techniques are needed to fit the multicast environment 😤. Each packet will need its own independent cryptographic processing, so packets from multiple sources can be decrypted independently by the many receivers, especially when packets get lost 📦. N-party authentication and key management will be required to set up the shared key among the right 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 after individual authentication, and this could be trivially implemented using PEM technology 🎀. The overhead on each host computer in the conference will be similar to that of existing point-to-point encryption apps 💻. It's low enough that software encryption today can give adequate performance for whiteboard and voice traffic, while hardware encryption is adequate for video 🎬.

Multicast also adds an extra requirement ✨. Existing multicast conferences degrade gradually in quality as the packet loss rate goes up 📉. To be acceptable, authentication protocols must tolerate lost packets 🥹. Techniques that do this efficiently still need to be developed. One initial sketch is outlined below, but engineering work will be required to validate that this approach is practical 🛠️💖.

This part picks up mid-thought in the middle of section 6.1's wrap-up, so we just keep rolling.

okay so symmetric encryption is seriously good at keeping outsiders out 🔐 but because every conference member shares ONE key, it can't tell you which member is actually talking. 🙈 In theory, one-way hash functions (MD5 is the example here) plus digital signatures built on asymmetric encryption could give you individual authentication. The hashes are basically as cheap as symmetric encryption, but digital signatures are way more expensive, both in computation AND in how big the messages get 💀. How much overhead you eat depends on how strong an authentication you need.

Lowkey the summary is: real-time authentication at the group-membership level is easy and cheap ✨, but authenticating each individual is costly in time and space 😭. Costs for communications and processing are expected to drop over time, so individual authentication might become doable for each conference participant 🦋. BUT there are two trends fighting each other 🥊: (1) CPUs getting faster so symmetric encryption is quicker, and (2) data rates getting faster too. If both grow at the same pace, there's no net gain, at least if you measure the grain size in bits instead of in seconds. Not me going "wait, so the speedup cancels out?" 💅

The group felt the right move for end-to-end controls is encryption, as we talked about above 🎀. The other option is to control whether a user can join a multicast group as a listener or as a speaker. But ngl, we're not comfy with how much assurance we can actually give if we try to get end-to-end semantics that way 🙅‍♀️. Any passive penetration of the network (aka a wire-tap) can compromise the privacy of the transmitted information 👀. We do have to admit that problems with deploying encryption code and hardware, and especially export controls, will push people toward using the tools from Section 4 to build some form of end-to-end control 🫠. That decision wouldn't raise any new issues in security technology, honestly. The shared key already used for encrypting data could also be the basis for authenticating a multicast group join request. That would need a change to the multicast packet format, but nothing more 🧚. Our worry isn't how technically hard this is. It's the level of assurance we can offer the user 💜.

6.2. Secure Plug-and-Play a Must ✨

okay so plug-and-play is when you plug a brand-new device into a network and it just figures it all out 🔌, getting what it needs to talk to other devices without you typing in any new configuration 🙌. Secure plug-and-play is a big deal for the Internet, and the central architecture question is whether it can scale well 🌸.

For plug-and-play to work, a new machine that gets "plugged" in needs to:

Obtain an locator so it can communicate with other devices
Register or obtain a name to be identified by (e.g., machine name)
Discover services available on the network (e.g., printers, routers, file servers, etc.)
Discover other systems on the network so it can communicate with them.

In some environments, no security mechanisms are needed because physical security and local knowledge of the users are enough protection 🍓. On the other end of the spectrum is a huge network with lots of groups of users, all kinds of outside connections, and different levels of admin control 🌈. There, you need similar plug-and-play capabilities, but the new device has to be "authenticated" before it can do any of this 🔐. At every step of the discovery process, the new device must authenticate itself before it learns anything about services. It's giving security checkpoint energy 💅.

The steps might look like this:

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.

Setting up a box you just took out of the packaging is basically the same problem as a laptop or phone that a person wants to hook up to a local network for a little while to get services 💻. How does the local network verify the human (and therefore their machine) and know which services that visiting machine is allowed to use? 🤔

The human gets a high-level identifier (HLID) that works like their passport and can be verified by the local network 🛂. This identifier must be globally unique and registered or assigned by some recognized authority 🌍.

When the human plugs the machine into a local net, the machine tells the net who it is using the human's HLID 🪪. If the local net has a policy of letting anyone plug and play, it'll ignore the HLID, give the visitor an address (locator), and let them have unrestricted access and privileges 🫢. But more likely, the local net will authenticate the HLID before granting the visitor an address or any privileges 🔒.

Here's the catch: at this point, the HLID has only authenticated the visitor to the local network. Which services or resources the visitor is entitled to use still hasn't been figured out 😩. It's desirable to develop a low-overhead approach to granting authentications to new users. That would help with visitors to a site, and with new users joining a facility 🎀.

6.3. A Short-Term Confidentiality Mechanism 🦋

okay passwords have been the classic way to authenticate 🔑. With no active attacks going on, the biggest threat to computer security might be how easily passwords can get "snooped" by promiscuous monitoring of shared-media networks 👀. There are known security techniques that do authentication without exposing passwords to interception, like the ones in the well-known Kerberos system 🐕‍🦺. The catch is that authentication systems like Kerberos currently only work in isolation within organizational boundaries 🏰. Building and deploying a global authentication infrastructure is a super important goal, but it's gonna take some years ⏳. In the meantime, a useful short-term approach is a challenge-response user authentication scheme (e.g., S/Key) 🧩.

One of the groups explored another interim approach to guarding passwords: a readily used confidentiality mechanism based on an encrypted TCP connection 🔐. This would work at the IP level to encrypt the IP payload, including the TCP header, so both the nature and the contents of the communication stay private 🤫. It could be set up to give either "strict" protection (the connection fails if the other side can't 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 way 💖.

One-time keys may be exchanged during the SYN handshake that starts the TCP connection ✨. Using one-time keys avoids the need for infrastructure support and doesn't require trust between the organizations on the two ends of the connection 🫶. Tying the key exchange to the SYN handshake avoids the possibility of having the connection fully open without knowing the state of encryption on both ends 🙈. Still, it may be theoretically possible to intercept the SYN exchange and subvert the connection with an active "man-in-the-middle" attack. In practice, though, attacks like that 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 it's willing to use. If there's no acknowledgement, that implies it's not interested in decrypting the datastream 🙅‍♀️. If a loose privacy policy is 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 cryptanalysis of the Diffie-Hellmann scheme may require a very long modulus, e.g., 1024 bits, and that can't be carried in the 40 bytes available for TCP options 💀. So you'd have to either define an "extended option" format or implement encryption in a separate protocol layered between TCP and IP, perhaps using a version of "IP security" 🧠. The detailed engineering of a solution like that would have to be studied by a working group 📋.

A TCP connection encryption mechanism like this requires no application changes, although it does require kernel changes 🧑‍💻. It has some 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 also be patent issues 📜.

7. CONCLUSIONS ✨

okay bestie, the big takeaway is that security has to get added to the Internet incrementally 🧩. if a scheme needs application code, the DNS, routers, AND firewalls all changed at the same time before you see ANY improvement, it's gonna be super hard to deploy 😭. that's a big reason the workshop looked at schemes that live local to the IP layer, because we figured those might be way easier to roll out in real life 🦋

there are two competing observations that have to shape how we plan Internet security 💅. first, the classic "the best is the enemy of the good" 🫶. second, the attacks are getting better 💀.

and ngl, the principle of least privilege (which we talked about above) might clash with the principle of least cost 🙈.

7.1. Suggested Short-Term Actions

the general vibe for short-term Internet security policy was that the IETF should make a list of desirable short-term actions and then team up with other organizations to actually carry them out 🤝. those other orgs include regionals, who are in a really good spot to offer site security counseling to their customers, vendors, and other providers 🎀, plus other societies. we should also give input to the US government so its posture on security moves in the direction the community wants 🇺🇸✨.

a preliminary list of short-term actions got drafted:

Perform external diagnostic security probes 🔍
- Organizations should be encouraged to use CRACK and other tools to check how robust their own passwords are. 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 🙈
- Useful probe tools include:
  - ISS: Klaus (GA)
  - SATAN: Farmer Venema
  - ICEPICK: NRL
Determine Security-Risk Publication Channels 📢
- What channels should be used for disseminating information of security risks?
Encourage use of one-time passwords 🔑
- Available packages: S/Key, SecurID, Enigma, Digital Pathways.
Develop and publish guidelines for protocol developers, for security-friendliness and firewall-friendliness 📝
Control topology to isolate threats 🧱
Set privacy policy:
- Always
- As much as possible
Bring Site Security Handbook up to date 📚
Support use of Kerberos 🎫

the "Clipper chip" came up several times, but there wasn't enough discussion of this very complex issue for the group to reach a recommendation. it's been observed that there are a bunch of quite differing viewpoints about Clipper 🌈:

Some people accept the government's Clipper proposal, including key escrow by the US government and the requirement that encryption be in hardware.
Some people don't mind key escrow by the government in principle, but they object to the hardware requirement.
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.
Some people don't want key escrow at all.
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 need some protocol design or modification, BUT they use existing security technology and don't require any research 🛠️✨.

Authentication Protocol 🔐
- there's a problem with the choice of technology. public key technology is generally deemed superior, but it's patented and can also induce relatively long computations. symmetric key technology (the Needham-Schroeder algorithm, as used in Kerberos) has some technical drawbacks, but it isn't patented. a system based on symmetric keys and used only for authentication would be freely exportable without being subject to patents 🦋
Push Kerberos 🚀
- engineering is needed on Kerberos so it can interoperate with mechanisms that use public key cryptography.
Push PEM/RIPEM/PGP... 💌
Develop an authenticated DNS 🌐
Develop a key management mechanism 🗝️
Set up a certificate server infrastructure 🏛️
- possible server mechanisms include the DNS, Finger, SNMP, Email, Web, and FTP.
Engineer authentication for the Web 🕸️

7.3. Suggested Long-Term Actions

okay so this category is for situations where a threat has been identified and solutions are imaginable, but the group hasn't closed the loop on the principles yet 🔮. the open ones are:

Executable Apps 🧩
Router sabotage counter-measures 🚨
Prevent Byzantine routing. 🕸️
Proxy Computing 🧚
Decomposition of computers 💜
Are there "good" viruses? 🦠🙈

APPENDIX A -- Workshop Organization ✨

okay so this appendix is the who's who of the workshop 💅 It lists everyone and which breakout group they were put in. Some names also have a tag in parentheses, which is where they sat in the community structure at the time 🎀

Breakout Groups 👯

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:

     Scott Bradner, Harvard           (IPng AD)
     Jon Postel, ISI                  (IAB)

Quick heads-up: the leaders are the first person listed in each group, and the two people who could only make day three are at the bottom 🫶

The Workshop Agenda 🗓️

okay the schedule is packed 😭 Tuesday kicks off with plenary sessions and breakouts, Wednesday gets into the deeper requirement work, and Thursday is all about wrapping up and the security talks. Here's the full timetable:

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
          14:30 - 16:00  Plenary --  Long- and Medium-term
                                     Recommendations

The Starting Scenarios 🎬

the scenarios are where the drama is 🍓 They were the starting point for all the discussions. The big idea was to split security-S (security as a service to the end systems) from security-M (security as a mechanism that supports other services). The workshop was mainly about how these different services interact:

Security-S
Routing
Multi-destination delivery (mcast-S)
Realtime Packet scheduling (realtime)
Mobility
Accounting

(and maybe large-scale?)

Those categories got applied to these 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]

   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]

Now the leftovers 🧁 The next batch of suggested scenarios didn't fit the main thrust of the workshop, mostly because they're single-issue topics. Most of them are pure security topics about the security perimeter. The last two don't fit the 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
        media (data, voice, video).

Security Considerations 🔐

Okay bestie, this part is SERIOUS 😭🔐 Literally the whole memo is about security issues:

This memo is entirely concerned with security issues.

Authors' Addresses 💌

and finally, the people behind the document and how to reach them 🦋

   Bob Braden [Editor]
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695

   Phone: (310) 822-1511
   EMail: Braden@ISI.EDU


   David Clark
   MIT Laboratory for Computer Science
   545 Technology Square
   Cambridge, MA 02139-1986

   Phone: 617-253-6003
   EMail: ddc@lcs.mit.edu


   Steve Crocker
   Trusted Information Systems, Inc.
   3060 Washington Road (Rte 97)
   Glenwood, MD 21738

   Phone: (301) 854-6889
   EMail: crocker@tis.com


   Christian Huitema
   INRIA, Sophia-Antipolis
   2004 Route des Lucioles
   BP 109
   F-06561 Valbonne Cedex
   France

   Phone:  +33 93 65 77 15
   EMail: Christian.Huitema@MIRSA.INRIA.FR

That's the whole document, bestie! 🌈💖✨

📦 where this page comes from

ietf: rfc1636 1994-06
💖 girlified by claude-haiku-5-5 on 2026-10-15: a language model's rewrite of the original, under its terms