RFC 1825

Security Architecture for the Internet Protocol

📅 published August 1995, from ietf

RFC 1825: Security Architecture for the Internet Protocol 💖

Okay so this one is by R. Atkinson from the Naval Research Laboratory, published in August 1995 as a Standards Track document from the Network Working Group 🎀 The header doesn't list anything it obsoletes or updates, so it's standing on its own 💅

Status of this Memo ✨

This document specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 🫶 If you want to know where this protocol stands in terms of standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📋 And yep, distribution of this memo is unlimited 🌈

1. INTRODUCTION ✨

Okay bestie, so this memo covers the security mechanisms for IP version 4 (IPv4) and IP version 6 (IPv6), plus the services those mechanisms provide 🔐 Each security mechanism gets its own separate document. This one also covers the key management requirements for systems that implement those mechanisms 🗝️ It is not an overall Security Architecture for the Internet, though. It's laser-focused on IP-layer security 💅

1.1 Technical Definitions

Before we get into the good stuff, here are some basic definitions 📚 Other documents give more definitions and background, too [VK83, HA94] 🧚

  • Authentication Knowing that the data you received is the same as the data that was sent, AND that the claimed sender is actually the one who sent it 🫶
  • Integrity Data gets from source to destination without anyone altering it in a way that goes unnoticed 🛡️
  • Confidentiality You communicate so the intended recipients know what was sent, but unintended parties can't work out what was sent 🤫
  • Encryption A mechanism commonly used to provide confidentiality 🔒
  • Non-repudiation A receiver can prove that the sender really did send some data, even if the sender later tries to deny ever sending it 📜
  • SPI Short for "Security Parameters Index" 🆔 It's an unstructured, opaque index used together with the Destination Address to identify a particular Security Association.
  • Security Association The set of security information for a given network connection or set of connections. It's described in detail below 📦
  • Traffic Analysis Analyzing network traffic flow to deduce information that's useful to an adversary 🕵️‍♀️ Examples include frequency of transmission, the identities of the conversing parties, sizes of packets, Flow Identifiers used, etc. [Sch94]

1.2 Requirements Terminology

In this document, the words that define how significant each requirement is are usually capitalised 🔠 Here they are:

  • MUST This word or the adjective "REQUIRED" means that the item is an absolute requirement of the specification. 👑
  • SHOULD This word or the adjective "RECOMMENDED" means there might be valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before taking a different course. 🤔
  • MAY This word or the adjective "OPTIONAL" means the item is truly optional. One vendor might include it because a particular marketplace requires it or because it enhances the product, for example, and another vendor may omit the same item. 🎀

1.3 Typical Use

Okay so there are two headers that do the security work in IPv4 and IPv6 🎁 One is the "IP Authentication Header (AH)" [Atk95a], and the other is the "IP Encapsulating Security Payload (ESP)" [Atk95b] header. There are a bunch of ways these might get used, and this section covers some of the more likely ones. These descriptions aren't complete or exhaustive, and other uses can be dreamed up too ✨

The IP Authentication Header is designed to give you integrity and authentication without confidentiality 🧁 Why skip confidentiality? Because that lack of confidentiality means AH implementations will be widely available on the Internet, even in places where exporting, importing, or using encryption for confidentiality is regulated 🌍 AH supports security between two or more hosts implementing AH, between two or more gateways implementing AH, and between a host or gateway implementing AH and a set of hosts or gateways 🤝

Here's the gateway stuff. A security gateway is a system that acts as the communications gateway between external untrusted systems and trusted hosts on their own subnetwork 🚪 It also provides security services for those trusted hosts when they communicate with the external untrusted systems. A trusted subnetwork contains hosts and routers that trust each other not to engage in active or passive attacks, and they trust that the underlying communications channel (e.g., an Ethernet) isn't being attacked 🫂

When a security gateway is providing services on behalf of one or more hosts on a trusted subnet, the gateway is the one responsible for establishing the security association on behalf of its trusted host. It's also responsible for providing security services between itself and the external system(s) 🧚 In this case, only the gateway needs to implement AH, while all of the systems behind the gateway on the trusted subnet are allowed to take advantage of AH services between the gateway and external systems 💖

A security gateway that receives a datagram carrying a recognised sensitivity label, for example IPSO [Ken91], from a trusted host should take that label's value into consideration when creating/selecting a Security Association for use with AH between the gateway and the external destination 🏷️ In an environment like that, a gateway that receives an IP packet containing the IP Encapsulating Security Payload (ESP) should add appropriate authentication, including implicit (i.e., contained in the Security Association used) or explicit label information (e.g., IPSO), for the decrypted packet it forwards to the trusted host that is the ultimate destination. The IP Authentication Header should always be used on packets containing explicit sensitivity labels, so you get end-to-end label integrity 🔗

🚨 In environments using security gateways, those gateways MUST perform address-based IP packet filtering on unauthenticated packets purporting to be from a system known to be using IP security. No skipping this one, bestie 🚨

The IP Encapsulating Security Payload is designed to provide integrity, authentication, and confidentiality to IP datagrams [Atk95b] 🎀 ESP supports security between two or more hosts implementing ESP, between two or more gateways implementing ESP, and between a host or gateway implementing ESP and a set of hosts and/or gateways 🫶 A security gateway, again, is a system that acts as the communications gateway between external untrusted systems and trusted hosts on their own subnetwork, and it provides security services for those trusted hosts when they talk to external untrusted systems. A trusted subnetwork contains hosts and routers that trust each other not to engage in active or passive attacks, and trust that the underlying communications channel (e.g., an Ethernet) isn't being attacked. Trusted systems always should be trustworthy, but in practice they often are not trustworthy 😬

Gateway-to-gateway encryption is most valuable for building private virtual networks across an untrusted backbone, like the Internet 🌐 It does this by excluding outsiders. As a result, it's often not a substitute for host-to-host encryption, and honestly the two can be, and often should be, used together 💜

In the case where a security gateway is providing services on behalf of one or more hosts on a trusted subnet, the gateway is responsible for setting up the security association for its trusted host and for providing security services between itself and the external system(s) 🧚 In this case, only the gateway needs to implement ESP, while all of the systems behind the gateway on the trusted subnet are allowed to take advantage of ESP services between the gateway and external systems ✨

A gateway that receives a datagram containing a recognised sensitivity label from a trusted host should take that label's value into consideration when creating/selecting a Security Association for use with ESP between the gateway and the external destination 🏷️ In such an environment, a gateway that receives an IP packet containing the ESP should appropriately label the decrypted packet that it forwards to the trusted host that is the ultimate destination. The IP Authentication Header should always be used on packets containing explicit sensitivity labels to ensure end-to-end label integrity 🔗

If there are no security gateways in the connection, then two end systems that implement ESP can also use it to encrypt only the user data (e.g., TCP or UDP) being carried between the two systems 🧁 ESP is built for maximum flexibility, so users can select and use only the security they actually desire and need 💅

Routing headers for which integrity hasn't been cryptographically protected SHOULD be ignored by the receiver 🙅‍♀️ If this rule isn't strictly followed, the system becomes vulnerable to various kinds of attacks, including source routing attacks [Bel89] [CB94] [CERT95] 💀

While these documents don't specifically discuss IPv4 broadcast, these IP security mechanisms MAY be used with such packets 🌸 Key distribution and Security Association management aren't trivial for broadcast applications 😭 Also, if symmetric key algorithms are used, cryptography with a broadcast packet has limited value, because the receiver can only know the received packet came from one of many systems that know the correct key to use 🔑

1.4 Security Associations ✨

okay bestie, the "Security Association" is literally the foundation of both the IP Encapsulating Security Payload and the IP Authentication Header 🫶. A given Security Parameter Index (SPI) plus a Destination Address uniquely identifies one particular "Security Association" 🔑. Any implementation of the Authentication Header or the Encapsulating Security Payload MUST support this concept 💅. It MAY also support other parameters too. A Security Association normally includes the parameters below, but it might have extra ones as well:

  • Authentication algorithm and algorithm mode being used with the IP Authentication Header [REQUIRED for AH implementations].
  • Key(s) used with the authentication algorithm in use with the Authentication Header [REQUIRED for AH implementations].
  • Encryption algorithm, algorithm mode, and transform being used with the IP Encapsulating Security Payload [REQUIRED for ESP implementations].
  • Key(s) used with the encryption algorithm in use with the Encapsulating Security Payload [REQUIRED for ESP implementations].
  • Presence/absence and size of a cryptographic synchronisation or initialisation vector field for the encryption algorithm [REQUIRED for ESP implementations].
  • Authentication algorithm and mode used with the ESP transform (if any is in use) [RECOMMENDED for ESP implementations].
  • Authentication key(s) used with the authentication algorithm that is part of the ESP transform (if any) [RECOMMENDED for ESP implementations].
  • Lifetime of the key or time when key change should occur [RECOMMENDED for all implementations].
  • Lifetime of this Security Association [RECOMMENDED for all implementations].
  • Source Address(es) of the Security Association, might be a wildcard address if more than one sending system shares the same Security Association with the destination [RECOMMENDED for all implementations].
  • Sensitivity level (for example, Secret or Unclassified) of the protected data [REQUIRED for all systems claiming to provide multi-level security, RECOMMENDED for all other systems].

The sending host uses the sending userid and Destination Address to pick the right Security Association (and therefore the SPI value) 🎀. The receiving host uses the combo of SPI value and Destination Address to figure out which association is the correct one. So an AH implementation will always be able to use the SPI together with the Destination Address to find the security association and related security configuration data for all valid incoming packets ✨. When a formerly valid Security Association becomes invalid, the destination system(s) SHOULD NOT immediately reuse that SPI value. Instead, they SHOULD let that SPI value go stale before reusing it for some other Security Association 🥹.

A security association is normally one-way 🦋. An authenticated communications session between two hosts will normally have two Security Parameter Indexes in use, one in each direction. The combination of a particular Security Parameter Index and a particular Destination Address uniquely identifies the Security Association. The Destination Address may be a unicast address or a multicast group address 🌈.

The receiver-orientation of the Security Association means that, for unicast traffic, the destination system will normally select the SPI value 👑. Letting the destination pick the SPI means there's no chance of manually configured Security Associations clashing with automatically configured ones (for example, ones set up through a key management protocol). Multicast is trickier. There are multiple destination systems but only one destination multicast group, so some system or person will need to select SPIs on behalf of that group and then pass the information along to all the legitimate members of that group through mechanisms not defined here 🧚.

Multiple senders to a multicast group MAY use a single Security Association (and therefore a single Security Parameter Index) for all traffic to that group. In that case, the receiver only knows the message came from a system that knows the security association data for that multicast group 🫣. A receiver generally cannot authenticate which system sent the multicast traffic when symmetric algorithms (e.g., DES, IDEA) are in use. Multicast traffic MAY also use a separate Security Association (and therefore a separate SPI) for each sender to the multicast group. If each sender has its own Security Association and asymmetric algorithms are used, then data origin authentication is also a provided service 💜.

2. DESIGN OBJECTIVES 🎯

This section covers some of the design objectives of this security architecture and its component mechanisms. The main goal here is making sure IPv4 and IPv6 both have solid cryptographic security mechanisms available for users who want security 💖.

These mechanisms are designed to avoid adverse impacts on Internet users who don't use them for their traffic 🫶. They're intended to be algorithm-independent, so the cryptographic algorithms can be swapped out without affecting the other parts of the implementation 🔄. These security mechanisms should be useful for enforcing a variety of security policies 💅.

Standard default algorithms (keyed MD5, DES CBC) are specified to ensure interoperability across the global Internet 🌍. The selected default algorithms are the same standard defaults used in SNMPv2 [GM93] ✨.

3. IP-LAYER SECURITY MECHANISMS 🔐

There are two cryptographic security mechanisms for IP 💜. The first is the Authentication Header, which provides integrity and authentication without confidentiality [Atk95a]. The second is the Encapsulating Security Payload, which always provides confidentiality and, depending on algorithm and mode, might also provide integrity and authentication [Atk95b]. The two IP security mechanisms may be used together or separately 🦋.

These IP-layer mechanisms don't provide security against a number of traffic analysis attacks 🙈. There are some techniques outside the scope of this specification (e.g., bulk link encryption) that might be used to protect against traffic analysis [VK83].

3.1 AUTHENTICATION HEADER 🛡️

The IP Authentication Header holds authentication information for its IP datagram [Atk95a]. It does this by computing a cryptographic authentication function over the IP datagram and using a secret authentication key in the computation 🔑. The sender computes the authentication data before sending the authenticated IP packet. Fragmentation happens after Authentication Header processing for outbound packets, and before Authentication Header processing for inbound packets. The receiver verifies the correctness of the authentication data on reception ✅.

Certain fields that must change in transit, such as the TTL (IPv4) or Hop Limit (IPv6) field (which is decremented on each hop), are left out of the authentication calculation. The omission of the Hop Limit field does not adversely impact the security provided 🙌. Non-repudiation might be provided by some authentication algorithms (e.g., asymmetric algorithms where both sender and receiver keys are used in the authentication calculation) used with the Authentication Header. It isn't necessarily provided by all authentication algorithms that might be used with the Authentication Header 🤔. The default authentication algorithm is keyed MD5, which, like all symmetric algorithms, cannot provide non-repudiation by itself. Confidentiality and traffic analysis protection are not provided by the Authentication Header 🙈.

Using the Authentication Header will increase the IP protocol processing costs in participating systems, and it will also increase communications latency 🐢. The extra latency comes mainly from the sender calculating the authentication data, and from each receiver calculating and comparing the authentication data for each IP datagram containing an Authentication Header (AH).

The Authentication Header provides much stronger security than most of today's Internet has, and it should not affect exportability or significantly increase implementation cost 💪. The Authentication Header might be implemented by a security gateway on behalf of hosts on a trusted network behind that gateway, but this mode of operation is not encouraged 🙅‍♀️. Instead, the Authentication Header should be used from origin to final destination 🎯.

All IPv6-capable hosts MUST implement the IP Authentication Header with at least the MD5 algorithm using a 128-bit key. IPv4-systems claiming to implement the Authentication Header MUST implement the IP Authentication Header with at least the MD5 algorithm using a 128-bit key [MS95]. An implementation MAY support other authentication algorithms in addition to keyed MD5 🚨.

3.2 ENCAPSULATING SECURITY PAYLOAD 🎁

The IP Encapsulating Security Payload (ESP) is designed to provide integrity, authentication, and confidentiality to IP datagrams [Atk95b] 💖. It does this by encapsulating either an entire IP datagram or only the upper-layer protocol data (e.g., TCP, UDP, ICMP) inside the ESP. It then encrypts most of the ESP contents and appends a new cleartext IP header to the now-encrypted Encapsulating Security Payload 🔒. That cleartext IP header is what carries the protected data through the internetwork 🚚.

3.2.1 Description of the ESP Modes 🌸

There are two modes within ESP ✨. The first, known as Tunnel-mode, encapsulates an entire IP datagram within the ESP header. The second, known as Transport-mode, encapsulates an upper-layer protocol (for example UDP or TCP) inside ESP and then prepends a cleartext IP header 🦋.

3.2.2 Usage of ESP 🧁

ESP works between hosts, between a host and a security gateway, or between security gateways 🌐. This support for security gateways lets trustworthy networks behind a security gateway skip encryption, avoiding the performance and monetary costs of encryption, while still providing confidentiality for traffic crossing untrustworthy network segments 💸. When both hosts directly implement ESP and there is no intervening security gateway, they may use Transport-mode (where only the upper-layer protocol data, e.g., TCP or UDP, is encrypted and there is no encrypted IP header). This mode cuts down on both the bandwidth consumed and the protocol processing costs for users who don't need to keep the entire IP datagram confidential 🫶.

ESP works with both unicast and multicast traffic 🥰.

3.2.3 Performance Impacts of ESP 🧚

okay bestie, let's talk performance 💅 ESP can noticeably affect network performance in the systems that are participating, but it should not adversely impact routers or other intermediate systems that aren't part of that particular ESP association. the middle-of-the-network boxes just keep doing their thing 🦋

the participating systems have it harder though 😭 protocol processing gets more complex when encapsulating security is used, so it takes more time and more processing power. encryption also bumps up communications latency 🫶 the latency mostly comes from the encryption and decryption that's needed for every IP datagram carrying an Encapsulating Security Payload. the exact cost of ESP depends on the implementation, like the encryption algorithm, the key size, and other factors. if high throughput is the goal, hardware implementations of the encryption algorithm are recommended 💜

for interoperability across the worldwide Internet, all conforming implementations of the IP Encapsulating Security Payload MUST support the use of the Data Encryption Standard (DES) in Cipher-Block Chaining (CBC) Mode, as detailed in the ESP specification 🎀 other confidentiality algorithms and modes may also be implemented on top of that mandatory one ✨

export and use of encryption are regulated in some countries [OTA94] 🙈

3.3 COMBINING SECURITY MECHANISMS 🎀

okay so sometimes the IP Authentication Header and the IP Encapsulating Security Protocol get paired up to get the security properties you want 👑 the Authentication Header always gives integrity and authentication, and it can give non-repudiation too if you use certain authentication algorithms (e.g., RSA) 🔥 the Encapsulating Security Payload always gives integrity and confidentiality, and it can also give authentication if you use certain authenticating encryption algorithms 💖

putting the Authentication Header on an IP datagram before you encapsulate it with the Encapsulating Security Protocol might be a vibe for users who want strong integrity, authentication, and confidentiality, and maybe also strong non-repudiation 💅 when the two are combined, where the Authentication Header sits makes it super clear which part of the data is being authenticated 🧚 all the details on combining the two are in the IP Encapsulating Security Payload specification [At94b] 🫶

3.4 OTHER SECURITY MECHANISMS 🌈

not me being the bearer of bad news, but none of the security mechanisms above protect against traffic analysis 🙈 it's unclear whether meaningful protection from traffic analysis can be provided economically at the Internet Layer, and it looks like not many Internet users are worried about traffic analysis anyway 💀

the traditional way to protect against traffic analysis is bulk link encryption 🔐 another technique is to send false traffic so there's more noise in the data that traffic analysis gets to look at 🦋 if you want the deeper dive, check out [VK83] 💜

4. KEY MANAGEMENT ✨

the Key Management protocol that gets used with IP layer security is not specified in this document 😭 but here's the tea: AH and ESP only connect to key management through the Security Parameters Index (SPI), so we can meaningfully define AH and ESP without fully specifying how key management is done 🧚 we expect several key management systems to work with these specs, including manual key configuration 🎀 work is ongoing within the IETF to specify an Internet Standard key management protocol 💅

key management methods where the key management data is carried within the IP layer are not a design objective for these IP-layer security mechanisms 🙈 instead, these mechanisms will mainly use key management methods where the data rides on an upper layer protocol, like UDP or TCP, on some specific port number, or where the data gets distributed manually 🫶

this design cleanly decouples the key management mechanism from the other security mechanisms, so you can swap in new and improved key management methods without touching the implementations of the other security mechanisms 👑 honestly that separation is so wise, given the long history of subtle flaws in published key management protocols [NS78, NS81] 💀 what follows is a brief look at a few alternative approaches to key management 🌸 mutually consenting systems may also use other key management approaches by private prior agreement 🌈

4.1 Manual Key Distribution 🍓

the simplest form of key management is manual key management, where a person manually configures each system with its own key and also with the keys of the other communicating systems 💅 this is pretty practical in small, static environments, but it does not scale 😭 it's not a viable medium-term or long-term approach, but it might be appropriate and useful in many environments in the near-term 🦋

a few examples where it totally works:

  • within a small LAN, it's entirely practical to manually configure keys for each system 🎀
  • within a single administrative domain, it's practical to configure keys for each router, so the routing data can be protected and the risk of an intruder breaking into a router is reduced 🔥
  • an organisation has an encrypting firewall between its internal network and the Internet at each of its sites, and it connects two or more sites via the Internet. the encrypting firewall might selectively encrypt traffic for other sites within the organisation using a manually configured key, while not encrypting traffic for other destinations 👑

manual distribution also might be appropriate when only selected communications need to be secured 🧚

4.2 Some Existing Key Management Techniques ✨

there are a bunch of key management algorithms described in the public literature 📚 Needham & Schroeder proposed a key management algorithm that relies on a centralised key distribution system [NS78, NS81] 🫶 that algorithm is used in the Kerberos Authentication System, developed at MIT under Project Athena [KB93] 🌸

Diffie and Hellman devised an algorithm that does not require a centralised key distribution system [DH76] 💖 unfortunately, the original Diffie-Hellman technique is vulnerable to an active "man in the middle" attack [Sch93, p. 43-44] 💀 however, this vulnerability can be mitigated by using signed keys to authentically bootstrap into the Diffie-Hellman exchange [Sch93, p. 45] 🛡️

4.3 Automated Key Distribution 🌈

widespread deployment and use of IP security will require an Internet-standard scalable key management protocol 👑 ideally, that protocol would support a number of protocols in the Internet protocol suite, not just IP security 🧚 there's work underway within the IETF to add signed host keys to the Domain Name System [EK94] The DNS keys let the originating party authenticate key management messages with the other key management party using an asymmetric algorithm 🔐 the two parties would then have an authenticatible communications channel that could be used to create a shared session key using Diffie-Hellman or other means [DH76] [Sch93] 🎀

4.4 Keying Approaches for IP 🦋

there are two keying approaches for IP 💅 the first one, host-oriented keying, has all users on host 1 share the same key for traffic destined for all users on host 2 🌸 the second one, user-oriented keying, lets user A on host 1 have one or more unique session keys for traffic destined for host 2, and those session keys are not shared with other users on host1 🫶 for example, user A's ftp session might use a different key than user A's telnet session 🍓

in systems claiming to provide multi-level security, user A will typically have at least one key per sensitivity level in use (e.g., one key for UNCLASSIFIED traffic, a second key for SECRET traffic, and a third key for TOP SECRET traffic) 👑 similarly, with user-oriented keying, one might use separate keys for information sent to a multicast group and control messages sent to that same multicast group 💜

in a lot of cases, a single computer system has at least two mutually suspicious users, A and B, who don't trust each other 😬 when host-oriented keying is used and mutually suspicious users exist, it's sometimes possible for user A to figure out the host-oriented key via well known methods, like a Chosen Plaintext attack 💀 once user A has improperly obtained the key in use, user A can then either read user B's encrypted traffic or forge traffic from user B 🙈 with user-oriented keying, certain kinds of attack from one user onto another user's traffic are not possible ✨

IP Security is intended to be able to provide Authentication, Integrity, and Confidentiality for applications running on connected end systems, when appropriate algorithms are in use 🔥 integrity and confidentiality can be provided by host-oriented keying when appropriate dynamic key management techniques and appropriate algorithms are in use 🧚 but authentication of principals using applications on end-systems requires that processes running applications can request and use their own Security Associations 🎀 that way, applications can use key distribution facilities that provide authentication 🫶

so, support for user-oriented keying SHOULD be present in all IP implementations, as described in the "IP Key Management Requirements" section below 👑💅

4.5 Multicast Key Distribution 🌸

multicast key distribution is an active research area in the published literature as of this writing 📚 for multicast groups with relatively few members, manual key distribution, or multiple uses of existing unicast key distribution algorithms such as modified Diffie-Hellman, appears feasible 🦋 for very large groups, new scalable techniques will be needed 😭 the use of Core-Based Trees (CBT) to provide session key management as well as multicast routing might be an approach used in the future [BFC93] 🌈

4.6 IP Key Management Requirements 🔑

okay bestie, this bit lays out the key management requirements for all IPv6 implementations, plus any IPv4 implementations doing the IP Authentication Header, the IP Encapsulating Security Payload, or both 🎀. It applies the same way to AH and ESP, no exceptions 💅

Every one of those implementations MUST support manual configuration of Security Associations 🔑. Non-negotiable, babe.

Every one of them SHOULD support an Internet standard Security Association establishment protocol (like IKMP or Photuris) once that protocol gets published as an Internet standards-track RFC 🦋. Lowkey the dream.

Implementations MAY also support other ways of configuring Security Associations, totally optional 🌸

Given two endpoints, it MUST be possible to have more than one concurrent Security Association between them 👑. Multiple keys at once, main character energy ✨. Implementations on multi-user hosts SHOULD support user granularity (aka "user-oriented") Security Associations 🧚

Every one of them MUST permit the configuration of host-oriented keying 💜

A device that encrypts or authenticates IP packets originated by other systems, like a dedicated IP encryptor or an encrypting gateway, generally can't provide user-oriented keying for traffic from those other systems 🙈. Such systems MAY additionally implement support for user-oriented keying for traffic originating on other systems 🌈. Extra credit, if they want it.

How keys actually get configured on a system is implementation-defined 🤷‍♀️. A flat file with security association identifiers and the security parameters (including the key(s)) is one example of a possible manual key distribution method 📁.

Any IP system MUST take reasonable steps to protect the keys and other security association info from unauthorised examination or modification 🔐.

Protect those keys like your life depends on it, because all of the security lies in the keys 💀

5. USAGE 🎀

this section shows how IP's security mechanisms can be used in different environments and applications, so implementers and users get a better idea of how these mechanisms cut down on security risks 🔥

5.1 USE WITH FIREWALLS 🧱

Firewalls are not uncommon on the current Internet [CB94] 👀. Lots of people hate them because they restrict connectivity, but they aren't going anywhere anytime soon. Both of these IP mechanisms can help firewalls do their job even better ✨.

Firewalls working with IP often need to parse the headers and options to figure out the transport protocol (like UDP or TCP) in use, plus the port number for that protocol 🔍. A firewall can be used with the Authentication Header whether or not it's party to the appropriate Security Association. But a firewall that isn't party to the applicable Security Association normally won't be able to decrypt an encrypted upper-layer protocol to see the protocol or port number it needs for per-packet filtering, or to verify that the data (source, destination, transport protocol, port number) used for access control decisions is correct and authentic 😬. So authentication might happen not just within an organisation or campus, but end to end with remote systems across the Internet 🌍. This use of the Authentication Header gives way more assurance that the data used for access control decisions is authentic 💅.

Organisations with two or more sites linked using commercial IP service might want a selectively encrypting firewall 🏢. If an encrypting firewall sat between each site of a company and the commercial IP service provider, it could give all of the company's sites an encrypted IP tunnel between each other 🚇. It could also encrypt traffic between the company and its suppliers, customers, and other affiliates 🤝. Traffic with the Network Information Center, public Internet archives, or some other organisations might not be encrypted, either because there's no standard key management protocol for it or as a deliberate choice to make communications easier, improve network performance, and boost connectivity. Still, this practice could easily protect the company's sensitive traffic from eavesdropping and modification 🛡️.

Some organisations (like governments) might want a fully encrypting firewall to provide a protected virtual network over commercial IP service 🕵️. The difference between that and a bulk IP encryption device is that a fully encrypting firewall also filters the decrypted traffic, on top of encrypting IP packets 🔍.

5.2 USE WITH IP MULTICAST 📡

The MBONE has grown super fast over the past few years 🚀. IETF meetings and other conferences are now regularly multicast with real-time audio, video, and whiteboards 🎥. Tons of people use teleconferencing apps based on IP Multicast, whether on the Internet or private internal networks 📞. Others use IP multicasting for distributed simulation or other apps 🧪. So it really matters that the security mechanisms in IP are suitable for an environment where multicast is the general case 💖.

The Security Parameters Indexes (SPIs) used in the IP security mechanisms are receiver-oriented, which makes them well suited for IP multicast [Atk95a, Atk95b] 🧚. Unfortunately, most currently published multicast key distribution protocols don't scale well 😩. There's active research in this area, though 🔬. As an interim step, a multicast group could repeatedly use a secure unicast key distribution protocol to distribute the key to all members, or the group could pre-arrange keys using manual key distribution 🗝️.

5.3 USE TO PROVIDE QOS PROTECTION 💫

The recent IAB Security Workshop identified Quality of Service protection as an area of significant interest [BCCH] 👑. The two IP security mechanisms are intended to give good support to real-time services as well as multicasting. This section describes one possible approach to providing that protection ✨.

The Authentication Header might be used, with appropriate key management, to provide authentication of packets 🔐. This authentication is potentially important for packet classification within routers 🧭. The IPv6 Flow Identifier might act as a Low-Level Identifier (LLID) 🏷️. Used together, packet classification within routers becomes straightforward if the router is provided with the appropriate keying material 🎯. For performance reasons, routers might authenticate only every Nth packet rather than every packet, but that's still a significant improvement over what the current Internet can do 📈. Quality of service provisioning is likely to also use the Flow ID in conjunction with a resource reservation protocol, such as RSVP [ZDESZ93] 🎀. So the authenticated packet classification can help make sure each packet gets appropriate handling inside routers 💅.

5.4 USE IN COMPARTMENTED OR MULTI-LEVEL NETWORKS 🕶️

A multi-level secure (MLS) network is one where a single network is used to communicate data at different sensitivity levels (like Unclassified and Secret) [DoD85] [DoD87] 🗂️. Many governments are seriously into MLS networking [DIA] 🏛️. The IP security mechanisms were designed to support MLS networking 💜. MLS networking needs strong Mandatory Access Controls (MAC), which ordinary users are incapable of controlling or violating [BL73] 🚫. This section only covers using these IP security mechanisms in MLS environments 📚.

The Authentication Header can be used to provide strong authentication among hosts in a single-level network 🤝. It can also provide strong assurance for both mandatory access control decisions in multi-level networks and discretionary access control decisions in all kinds of networks 💪. If explicit IP sensitivity labels (like IPSO) [Ken91] are used, and confidentiality isn't considered necessary in that operational environment, the Authentication Header is used to authenticate the entire packet, including cryptographic binding of the sensitivity level to the IP header and user data 🔗. This is a huge upgrade over labelled IPv4 networks, where the label gets trusted even though it isn't trustworthy, because there's no authentication or cryptographic binding of the label to the IP header and user data 😤. IPv6 will normally use implicit sensitivity labels that are part of the Security Association but aren't transmitted with each packet, instead of explicit sensitivity labels 🧁. All explicit IP sensitivity labels MUST be authenticated using either ESP, AH, or both 🔒.

The Encapsulating Security Payload can be combined with appropriate key policies to provide full multi-level secure networking 🌈. In this case, each key must be used only at a single sensitivity level and compartment. For example, Key "A" might be used only for sensitive Unclassified packets, while Key "B" is used only for Secret/No-compartments traffic, and Key "C" is used only for Secret/No-Foreign traffic 🗝️. The sensitivity level of the protected traffic MUST NOT dominate the sensitivity level of the Security Association used with that traffic 🚫. The sensitivity level of the Security Association MUST NOT dominate the sensitivity level of the key that belongs to that Security Association 🚫. The sensitivity level of the key SHOULD be the same as the sensitivity level of the Security Association 💖. The Authentication Header can also have different keys for the same reasons, with the choice of key depending in part on the sensitivity level of the packet 🎀.

Encryption is very useful and desirable even when all of the hosts are within a protected environment 🔐. The Internet-standard encryption algorithm could be used, in conjunction with appropriate key management, to provide strong Discretionary Access Controls (DAC) alongside either implicit sensitivity labels or explicit sensitivity labels (such as IPSO provides for IPv4 [Ken91]) 🗂️. Some environments might consider the Internet-standard encryption algorithm sufficiently strong to provide Mandatory Access Controls (MAC) 💪. Full encryption SHOULD be used for all communications between multi-level computers or compartmented mode workstations, even when the computing environment is considered to be protected 🔒.

6. SECURITY CONSIDERATIONS 🔐

Okay bestie, this whole memo is about the Security Architecture for the Internet Protocol 🧚. It is not a general security architecture for the Internet. It's laser-focused on the IP layer, so don't expect it to cover everything 💅.

🚨 Big warning, bestie: cryptographic transforms for ESP that use a block-chaining algorithm and lack a strong integrity mechanism are vulnerable to a cut-and-paste attack that Bellovin described [Bel95]. They should not be used unless the Authentication Header is always present with packets using that ESP transform. Please don't skip this one 💀

So, if more than one sender shares a Security Association with a destination, the receiving system can only authenticate that the packet came from one of those systems. It can't authenticate which one sent it 🙈. Same energy with Source Addresses: if the receiving system doesn't check that the Security Association used for a packet is valid for the packet's claimed Source Address, then it can't authenticate whether that claimed Source Address is valid either.

Here's the drama. Say senders "A" and "B" each have their own unique Security Association with destination "D". If "B" uses its valid Security Association with D but forges a Source Address of "A", then "D" will be fooled into believing the packet came from "A", unless "D" verifies that the claimed Source Address is party to the Security Association that was used. Main character plot twist 😭.

Users need to understand that the quality of the security these two IP security mechanisms provide depends completely on:

  • the strength of the implemented cryptographic algorithms,
  • the strength of the key being used,
  • the correct implementation of the cryptographic algorithms,
  • the security of the key management protocol, and
  • the correct implementation of IP and the several security mechanisms in all of the participating systems.

The security of the implementation is partly tied to the security of the operating system that embodies the security implementations 🖥️. For example, if the operating system does not keep the private cryptologic keys (that is, all symmetric keys and the private asymmetric keys) confidential, then traffic using those keys will not be secure. If any of these is incorrect or insufficiently secure, little or no real security will be provided to the user 😭.

Because different users on the same system might not trust each other, each user or each session should usually be keyed separately. This will also tend to increase the work required to cryptanalyse the traffic, since not all traffic will use the same key 🔑✨.

Certain security properties (e.g., traffic analysis protection) are not provided by any of these mechanisms 🙃. One possible approach to traffic analysis protection is appropriate use of link encryption [VK83]. Users must carefully consider which security properties they require, and take active steps to ensure that their needs are met by these or other mechanisms. No one gets security for free, bestie 💅.

Certain applications (e.g., electronic mail) probably need application-specific security mechanisms 📧. Those are out of scope for this document. Users interested in electronic mail security should consult the RFCs describing the Internet's Privacy-Enhanced Mail system. Users concerned about other application-specific mechanisms should consult the online RFCs to see if suitable Internet Standard mechanisms exist 🌸 iykyk.

ACKNOWLEDGEMENTS 🫶

Many of the concepts here are derived from, or were influenced by, the US Government's SDNS security protocol specifications, the ISO/IEC's NLSP specification, or the proposed swIPe security protocol [SDNS, ISO, IB93, IBK93]. The work done for SNMP Security and SNMPv2 Security influenced the choice of default cryptological algorithms and modes [GM93]. Steve Bellovin, Steve Deering, Richard Hale, George Kamis, Phil Karn, Frank Kastenholz, Perry Metzger, Dave Mihelcic, Hilarie Orman and Bill Simpson gave careful critiques of early versions of this document 🙌 Thank you, queens 👑

REFERENCES 📚

  • [Atk95a] Atkinson, R., "IP Authentication Header", RFC 1826, NRL, August 1995.
  • [Atk95b] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827, NRL, August 1995.
  • [BCCH94] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report of IAB Workshop on Security in the Internet Architecture", RFC 1636, USC/Information Sciences Institute, MIT, Trusted Information Systems, INRIA, June 1994.
  • [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989.
  • [Bel95] Steven M. Bellovin, Presentation at IP Security Working Group Meeting, Proceedings of the 32nd Internet Engineering Task Force, March 1995, Internet Engineering Task Force, Danvers, MA.
  • [BFC93] A. Ballardie, P. Francis, & J. Crocroft, "Core Based Trees: An Architecture for Scalable Inter-Domain Multicast Routing", Proceedings of ACM SIGCOMM 93, ACM Computer Communications Review, Volume. 23, Number 4, October 1993, pp. 85-95.
  • [BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems: Mathematical Foundations and Model", Technical Report M74-244, The MITRE Corporation, Bedford, MA, May 1973.
  • [CB94] William R. Cheswick & Steven M. Bellovin, Firewalls & Internet Security, Addison-Wesley, Reading, MA, 1994.
  • [DIA] US Defense Intelligence Agency, "Compartmented Mode Workstation Specification", Technical Report DDS-2600-6243-87.
  • [DoD85] US National Computer Security Center, "Department of Defense Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, US Department of Defense, Ft. Meade, MD., December 1985.
  • [DoD87] US National Computer Security Center, "Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria", NCSC-TG-005, Version 1, US Department of Defense, Ft. Meade, MD., 31 July 1987.
  • [DH76] W. Diffie & M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, Vol. IT-22, No. 6, November 1976, pp. 644-654.
  • [EK94] D. Eastlake III & C. Kaufman, "Domain Name System Protocol Security Extensions", Work in Progress.
  • [GM93] Galvin J., and K. McCloghrie, "Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1446, Trusted Information Systems, Hughes LAN Systems, April 1993.
  • [HA94] Haller, N., and R. Atkinson, "On Internet Authentication", RFC 1704, Bell Communications Research, NRL, October 1994.
  • [Hin94] Bob Hinden (Editor), Internet Protocol version 6 (IPv6) Specification, Work in Progress, October 1994.
  • [ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992.
  • [IB93] John Ioannidis and Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of USENIX Security Symposium, Santa Clara, CA, October 1993.
  • [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer Security for IP", presentation at the Spring 1993 IETF Meeting, Columbus, Ohio.
  • [Ken91] Kent, S., "US DoD Security Options for the Internet Protocol", RFC 1108, BBN Communications, November 1991.
  • [Ken93] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422, BBN Communications, February 1993.
  • [KB93] Kohl, J., and B. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, Digital Equipment Corporation, USC/Information Sciences Institute, September 1993.
  • [MS95] Metzger, P., and W. Simpson, "IP Authentication with Keyed MD5", RFC 1828, Piermont, Daydreamer, August 1995.
  • [KMS95] Karn, P., Metzger, P., and W. Simpson, "The ESP DES-CBC Transform", RFC 1829, Qualcomm, Inc., Piermont, Daydreamer, August 1995.
  • [NS78] R.M. Needham & M.D. Schroeder, "Using Encryption for Authentication in Large Networks of Computers", Communications of the ACM, Vol. 21, No. 12, December 1978, pp. 993-999.
  • [NS81] R.M. Needham & M.D. Schroeder, "Authentication Revisited", ACM Operating Systems Review, Vol. 21, No. 1., 1981.
  • [OTA94] US Congress, Office of Technology Assessment, "Information Security & Privacy in Network Environments", OTA-TCT-606, Government Printing Office, Washington, DC, September 1994.
  • [Sch94] Bruce Schneier, Applied Cryptography, Section 8.6, John Wiley & Sons, New York, NY, 1994.
  • [SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, published in NIST Publication NIST-IR-90-4250, February 1990.
  • [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.
  • [ZDESZ93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D. Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network magazine, September 1993.

DISCLAIMER

The views in this note are the author's own and not necessarily those of his employer. The Naval Research Laboratory has not passed judgement on the merits, if any, of this work. The author and his employer specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this design 🙅‍♀️

AUTHOR'S ADDRESS 📬

Randall Atkinson
Information Technology Division
Naval Research Laboratory
Washington, DC 20375-5320
USA

Phone:  (202) 767-2389
Fax:    (202) 404-8590
EMail: atkinson@itd.nrl.navy.mil
📦 where this page comes from