Key Recovery Header for IPSEC

Abstract

This document describes a mechanism for transmitting a key recovery header (KRH) within an IPSEC datagram. The KRH is normally inserted following the AH header and before the ESP header. The Key Recovery Header was designed to be compatible with IETF’s IPSEC Architecture.

Introduction

RFC 1825 defines the security architecture for the Internet. This paper proposes a method for carrying byte oriented Key Recovery Blocks (KRBs) [SG98] in a manner compatible with the IPSEC architecture.

The KRH is a mechanism for sending the KRBs from a sender, across the network to a receiver intercepting traffic as well as to the peer IPSEC implementation. The KRH does not provide confidentiality or integrity for the user data within the IP datagram. The KRH does provide integrity for the information contained in the KRH. The KRH is not protected by the ESP confidentiality mechanisms but portions of the KRH are protected by non-IPSEC mechanisms.

This document assumes the reader has previously read the related IP Security architecture document [Atk95a] which defines the overall security architecture for IP and provides important background information for this specification.

The key recovery header (KRH) seeks to provide key recovery capability by adding key recovery information to an IP datagram. This key recovery information is produced and protected in accordance with the specific key recovery technology identified within the KRH.

Use of the KRH will slightly increase the network bandwidth required. In order for the KRH to work properly without changing the entire Internet infrastructure, the key recovery data is carried in its own payload. Systems that aren’t participating in the key recovery MUST ignore the KRH. When used with IPv6, the KRH is normally placed after the Fragmentation, End-to-End and AH headers and before the ESP and transport-layer headers. When used with IPv4, the KRH immediately follows an IPv4 or Authentication header.

This section provides a few basic definitions that are applicable to this document. Other documents provide more definitions and background information [SG98], [RA95], [DM97].

In this document, the words that are used to define the significance of each particular requirement are usually capitalized. These words 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 that there might exist 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 that this item is truly optional. One vendor might choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item.

There are two specific headers that have been defined by the IETF to provide security services in IPv4 and IPv6. These headers are the ‘IP Authentication Header (AH)’ [Atk95a] and the ‘IP Encapsulating Security Payload (ESP)’ [Atk95b] header. This section introduces the key recovery header (KRH) and explains how it is typically used. These descriptions are not complete or exhaustive. Other uses can also be envisioned.

The KRH is designed to provide a means of transmitting the KRBs across the network so that they may be intercepted by an entity attempting to perform key recovery. As such, the KRH MUST NOT be encrypted by the ESP mechanisms. However, it SHOULD be protected from unauthorized modification using the AH mechanism. The KRH carries keying information about the ESP security association [RA95]. Therefore, KRH SHOULD only be used in conjunction with an ESP security association. The entity establishing the ESP security association SHOULD also establish the KRH security association. The KRH is generally not transmitted as part of every IPSEC packet. The frequency of KRH transmission is determined by the local policy of each IPSEC device. (e.g. once per hour) An IPSEC device which receives a KRH should silently discard it but MAY perform KRH integrity checking.

Intermediate network components (e.g., routers and firewalls) MUST pass the KRH without modification to the device which is responsible for the security association identified by the KRH Security Parameters Index (SPI).

This subsection describes some of the design objectives of the KRH and its component mechanisms. The primary objective of this work is to ensure that KRH information can be negotiated and transmitted within the IPSEC architecture. The KRH mechanisms are designed to avoid adverse impacts on Internet users who do not employ key recovery.