# **Items Exported From Working Group #5**

**Key Recovery Classifications**

> Key recovery may be broadly categorized into two types, private key
> recovery and session key recovery. Private key recovery may be
> implemented as a decryption key backup system implemented at public
> key pair, or symmetric KEK, generation time. In a public key
> cryptosystem, the KRA may optionally be specified in the user's
> encryption key certificate. When so implemented, private key recovery
> does not affect the interoperability of cryptographic applications.

Session key recovery is concerned with direct third party access to the
DEK. This is accomplished by requiring the cryptographic application to
designate the KRA as a cryptographic recipient of the encrypted data. To
recover the decrypted data, a requestor must have access to the
encrypted data and the key recovery field containing the DEK for the
data. Numerous techniques have been proposed to make session keys
recoverable. Setting aside variations specifically addressing secret
sharing, partial key escrow, timestamping, and certificates, these
techniques may be broadly categorized as algorithms which allow
authorized access to the DEK through the use of a key recovery block
within the cryptographic protocol.

**Protocol Classifications**

> The protocols which are to be session key recoverable fall broadly
> into two categories, transaction-based and session-based protocols.
> Application interoperability for the former is affected by the
> protocol's ability to support the designation of multiple
> cryptographic recipients. Insofar as the protocol supports multiple
> cryptographic recipients per transaction, a DEK wrapped for the
> designated KRA may be added without affecting interoperability. If it
> does not, then the addition of key recovery will cause recoverable and
> non-recoverable implementations to be non-interoperable.
>
> Session-based protocols exchange a session DEK during session
> initialization. The session DEK is then used to encrypt multiple PDU's
> for the duration of the session. This mode of operation is
> distinguished from transaction-based protocols which utilize a DEK for
> a single PDU. If session setup supports variable length fields during
> this initialization, a DEK wrapped for the KRA may be added without
> affecting application interoperability. If the initialization fields
> are fixed length, the addition of key recovery to these protocols will
> likely preclude interoperability with non-recoverable implementations.

**New WG1 Requirements**

> **5.1 In order to be FIPS compliant, there shall be a well-defined
> mapping from each component of the model to the implementation seeking
> certification.** Interoperability certification shall be determined
> through the interactions between the system components as defined by
> this mapping.

**5.2** I**nteroperable protocols which incorporate a FIPS-compliant
key-recovery mechanism must remain interoperable.** Users of FIPS
compliant implementations for the same protocol must have assurance that
these implementations will interoperate.

> **5.7 Compliant systems which implement private key recovery shall not
> affect protocol interoperability.** **Such systems may optionally
> specify a KRA in the user certificate.** As long as the originator is
> not required to retain the ability to subsequently decipher traffic,
> there are no interoperability issues in implementing private key
> recovery within a particular protocol.

**New WG1 Comments**

**5.3 Multiple techniques for key recovery shall be supported by the
FIPS.** These will include both private key and session key recovery
schemes.

> **5.4** **Receiver verification is desirable, but shall not be
> required for compliance.** High assurance receiver verification that
> an originator is using a recoverable implementation is a stated
> objective of this FIPS. If receiver verification is mandatory, then a
> single method of verification must be defined for such verification.
> If multiple methods are allowed, two compliant implementations using
> the same protocol may be unable to communicate. Further, verification
> may be dependent upon the KR mechanism used, implying that the
> specification of a single verification method may disallow some KR
> methods. It is worth noting that a finite set of verification methods
> poses the same problem as the single method assumed.

**5.5 When possible, the addition of compliant key recovery shall not
affect interoperability with non-recoverable implementations.** To
promote the use of FIPS compliant implementations, it is desirable for
compliant implementations to interoperate with the existing installed
base.

**5.11 The recovery request itself shall utilize FIPS-compliant key
recovery system.** To provide a means to monitor rogue KRR's and/or
KRA's it is necessary to incorporate compliant mechanisms for KRR to KRA
communications.

**New WG2 Requirement**

**5.10 The KR request message containing the subject key recovery field
and/or encrypted data shall be both digitally signed and encrypted.**
These services shall be applied to the KRR message to prevent forgery,
or manipulation of KRR data, as well as providing auditability for KR
requests.

# **FIPS Interoperability Working Group #5**

**Overview**

> The scope of this section is limited to discussion of issues related
> to the interoperability of key recoverable implementations within
> standards-based secure protocols. Although the addition of key
> recovery to a non-standard protocol should ideally maintain
> interoperability, the associated design decisions are assumed to be
> the purview of the individual product vendors.
>
> For the purposes of this section of the FIPS, two areas of
> interoperability are addressed. The first concerns the
> interoperability of individual protocols with, and without, the
> addition of FIPS-compliant key recovery. In particular, it is a
> requirement that compliant implementations of each protocol
> interoperate. To promote the use of this FIPS, the interoperability of
> recovery-enabled and non-recovery-enabled implementations is also at
> issue.
>
> A second area of interoperability to be addressed concerns the
> interoperability between a KRR and a KRA. To facilitate the
> verification and service of key recovery requests, an electronic
> protocol for servicing these requests must be defined. Given the
> nature of these requests, a secure messaging protocol is appropriate
> for these transactions.

**Interoperability Components**

> In order to certify interoperability, it is necessary to descibe the
> issues previously discussed within the framework of the Key Recovery
> FIPS Model. Interoperability can then be defined by the component
> interactions within this model which consists of the:

-   Key Recovery Requestor

-   Key Recovery Agent

-   Key Recovery Medium

-   Data Recovery Medium

> Interoperability between the KRR and a specific KRA is only an issue
> for electronic service requests and responses. These secure
> transactions may be sent using any of a variety of standard
> transaction-based security protocols. Interoperability compliance is
> determined by the ability of the KRR and KRA to process these
> transactions.
>
> At the protocol level there are should be no interoperability issues
> associated with private key recoverable schemes. This is attributable
> to the fact that when using private key recovery, the KRM and the DRM
> are entirely separate. Thus the addition of KR to the protocol has no
> effect at runtime.
>
> Conversely, session key recovery implies that the KRM and the DRM are
> the same. As a result the addition of session key recovery may pose
> interoperability issues with the protocol.

**Interoperability Requirements**

**5.1 An algorithm-independent secure Multipurpose Internet Mail
Extensions (MIME) format shall be utilized for electronic KRR to KRA
exchanges.** These transactions shall be cryptographically secured with
an assurance commensurate with the cryptosystem being recovered.
Compliant systems may choose from multiple well defined MIME formats.
These include the S/MIMEv3, PGP-MIME, and MOSS formats.

**5.2 A key recovery request shall include the following:**

-   **originator identiy**

-   **recipient identity**

-   **current date and time**

-   **date and time of key/data capture**

**5.3 A key recovery response shall include the following:**

-   **KRA identiy**

-   **KRR identity**

-   **current date and time**

-   **date and time of key/data recovery**

-   **requested key/data**

***[APPENDIX]{.underline}***

***Interoperability of Non-Key-Recoverable and Key-Recoverable
Systems***

> The interoperability of a non-key-recoverable product with a
> key-recoverable one appears to depend not so much on the key-recovery
> technique, as on whether or not there is a DRF or space for the
> addition of a KRF. If the session-based system uses a
> session-establishment protocol that ignores additional fields, then
> this is not an issue. However, for those products designed for a
> specific number of messages to be exchanged, often with a fixed
> length, the addition of a DRF received from a key-recoverable product
> will break interoperability. For these products, choosing a
> key-recovery technique that does not use a DRF may preserve
> interoperability.
>
> As a simple example, suppose two secure voice products each have fixed
> RSA private/public key pairs. Each generates a random number and
> exchanges it encrypted with the other's public key. Each decrypts the
> other's random number using its own private key and forms the session
> key by combining the two random numbers. If these products were
> modified to escrow the private keys, then with a recording of the key
> exchange, a KRA could form the session key. The addition of this
> key-recovery method does not use a DRF, and will not prevent a product
> whose private key is not escrowed from interoperating with a product
> whose private key is escrowed.

***Interoperability of Different Key-Recovery Techniques***

> Whether or not two session-based systems will interoperate when each
> has implemented a different key-recovery technique depends on the
> techniques chosen and the key-exchange protocol design.
>
> One example would be the case of a system that used a DRF and one that
> did not, with the further stipulation that each used the same basic
> key exchange. As a simple illustration, consider products A and B that
> each have a fixed RSA private-public key pair and use a
> session-establishment protocol, such that the one initiating the
> secure session generates a random session key and sends it to the
> other, encrypted with the other's public key. Product A sends no DRF,
> but can tolerate receiving one, and ignores it. Product A has escrowed
> its private key. Product B, on the other hand, has not escrowed its
> private key, but when it generates the session key, sends it encrypted
> with A's public key and sends a DRF containing the session key
> encrypted with product B's KRA's public key. Designed in this manner,
> A and B will interoperate with two different key-recovery techniques.
>
> Since this type of solution depends on an underlying key exchange
> protocol, and since so many exist for session-based systems, one could
> imagine a different key-recovery solution for each. Moreover, some key
> exchange protocols are expressly designed to build in key recovery
> with various properties.

## *S/MIME*

> The Secure MIME (S/MIME) protocol provides encryption for Internet
> electronic mail that uses the MIME encoding format. S/MIME defines two
> security wrappers: one for digital signatures and one for encryption.
> To encrypt and sign a message, both wrappers are applied. Both of
> these wrappers build on the formats defined in PKCS#7 version 1.5. For
> encryption, the EnvelopedData wrapper is used. The EnvelopedData
> wrapper requires RSA key management, and the RSA public keys must be
> carried in certificates.
>
> S/MIME does not include a location that can be used to carry a key
> recovery field. However, the key recovery center could be a recipient
> on every message, even if the message is not delivered to the key
> recovery center. In this way, the key recovery center private key can
> be used to recover the message plaintext content.
>
> Key recovery may also be done as part of certificate management. This
> technique only works if the originator is a recipient of the message.
> That is, a RecipientInfo field for the originator must be included to
> ensure that the key used to encrypt the message content is available
> to the key recovery center who holds a copy of the originator's RSA
> private key.

## *MSP*

> The Message Security Protocol (MSP) provides encryption for Internet
> and X.400 electronic mail. MSP is used in the Defense Message System,
> and MSP is specified in SDN.701. Like S/MIME, MSP supports both
> digital signatures and encryption; however, MSP defines one wrapper to
> provide both services. MSP is algorithm independent.
>
> MSP includes two locations that could be used to carry a key recovery
> field: the token and the extensions. To carry a key recovery field in
> the token, a separate object identifier for a new key management
> technique must be assigned. This approach would destroy
> interoperability with existing implementations. To carry a key
> recovery field in the extensions, a non-critical extension is added to
> the end of the message. MSP does not encrypt the extensions; therefore
> a key recovery field carried in an extension would be accessible.
>
> Alternatively, the key recovery center could be a recipient on every
> message, even if the message is not delivered to the key recovery
> center. In this way, the key recovery center private key can be used
> to recover the message plaintext content.
>
> Key recovery may also be done as part of certificate management. MSP
> includes a token for the originator. If the mail transfer system is
> unable to deliver the MSP protected message and returns the message to
> the originator as part of non-delivery notification, this token allows
> the originator to decrypt the message to determine which one was
> returned. If the key recovery center holds a copy of the originator's
> private key, then the key recovery center can also use the originator
> token to decrypt the message content.

## *PEM*

> The Privacy Enhanced Mail (PEM) protocol provides encryption for
> Internet electronic. PEM defines one encapsulation mechanism one for
> digital signatures and encryption. PEM is defined in Internet RFCs
> 1421 through 1424. Two forms of key management are supported for
> encryption: RSA key management using certificates and out-of-band
> distribution of symmetric key encryption keys.
>
> PEM includes one location that could be used to carry a key recovery
> field: the Key-Info header line. This header line is used for both
> forms of key management. To carry a key recovery field in the Key-Info
> line, a separate Date Encryption Key protection algorithm identifier
> must be assigned. This approach would destroy interoperability with
> existing implementations.
>
> Key recovery may also be done as part of certificate management. RFC
> 1421 recommends that a Key-Info header line be included for the
> originator as well as each recipient. This technique only works if the
> originator Key-Info header line is included. That is, a Key-Info
> header line for the originator must be included to ensure that the key
> used to encrypt the message content is available to the key recovery
> center who holds a copy of the originator's RSA private key. RFC 1424
> specifies the certificate management for PEM, and a single RSA key is
> used for key management and digital signature. Thus, this form of key
> recovery permits a malicious key recovery center to masquerade as the
> originator by generating signed PEM messages. These unauthorized
> messages could also be encrypted.

***ISAKMP \-- Work in progress by the Key Recovery Alliance***

> Both items below are the product of work-in-progress by the KRA
> technical WG. Please treat them with the appropriate sensitivity.
>
> *KRA members*
>
> Enclosed below is my updated proposal for providing key recovery in
> ISAKMP. I believe this will work from a protocol standpoint. However,
> we need to work with the IETF reps in our respective companies so that
> they can lobby the ISAKMP authors to meet our requirements.
>
> Proposed ISAKMP key recovery approach
>
> 5-14-97: Initial version
>
> 5-30-97: Updated to reduce Phase 1/2 confusion
>
> **1. PURPOSE**
>
> This technical note proposes a scheme for inserting a key recovery
> block (KRB) into the Internet Security Association Key Management
> Protocol (ISAKMP).
>
> **2. OVERVIEW**
>
> The requirements for the key recovery approach are that it MUST:

-   Comply with Government requirements for recovery, including tamper
    resistance.

```{=html}
<!-- -->
```
-   Allow interoperation of products from different vendors which have
    implemented different key recovery infrastructures.

```{=html}
<!-- -->
```
-   Allow a smooth migration from non-key recovery to key recovery such
    that products that implement key recovery can interoperate with
    products that do not implement key recovery.

> Three approaches were considered.

-   *Approach 1*: Give the recovery center your secret portion of the
    Diffie Hellman exchange. This approach was rejected because it does
    not work with the key recovery approaches already developed by some
    vendors. In addition, it gives the Government access to the
    authentication keys in addition to the encryption keys.

```{=html}
<!-- -->
```
-   *Approach 2*: Create a new ISAKMP exchange type. This approach was
    rejected because it fails to meet requirement 3 above. In addition,
    the political climate within the IETF makes it unlikely that this
    approach would make it through the standards process.

```{=html}
<!-- -->
```
-   *Approach 3*: Notification message. This approach is presented
    below. It minimizes the impact on ISAKMP specifications while
    meeting other requirements.

> The notification message approach uses the ISAKMP Header commit bit to
> prevent the use of keying material until the KRB has been received and
> validated by the peer ISAKMP implementation.
>
> The approach places a KRB into the Notification Data field of the
> Notification Payload. This information is authenticated by the
> authentication key (SKEYID_a) for the ISAKMP SA. This makes the
> approach tamper resistant.
>
> The details of the approach are presented in the following section.
>
> **3. DETAILED DISCUSSION**
>
> This section provides a detailed discussion of key recovery within the
> ISAKMP. It provides background on ISAKMP, discusses the
> sender/receiver packet processing and the packet contents.
>
> The ISAKMP specification is still an Internet draft. The latest
> version of this document may be obtained from
>
> http://www.ietf.cnri.reston.va.us/ids.by.wg/ipsec.html
>
> Much of the information in this section is taken directly from the
> February 21, 1997, version of the spec.
>
> The ISAKMP specification defines the following five exchange types.

-   Base exchange

```{=html}
<!-- -->
```
-   Identify Protection exchange

```{=html}
<!-- -->
```
-   Authentication Only exchange

```{=html}
<!-- -->
```
-   Aggressive exchange

```{=html}
<!-- -->
```
-   Informational exchange

> Key recovery information will be sent in the informational exchange.
>
> The ISAKMP supports the use of a commit flag bit which is carried in
> the ISAKMP header. When the commit bit is set it tells the receiver
> not to use the associated key in an IPSEC SA until the side setting
> the commit bit sends a \"connected\" notify message. This notify
> message is carried within the notification payload of the
> informational exchange.
>
> This bit was intended to give an ISAKMP/IPSEC device time to complete
> ISAKMP processing and move the key to the IPSEC engine before
> encrypted packets were sent. This can also be used to prevent the
> other device from using a key until the KRB has been transmitted.
>
> The commit flag is reset by sending the \"connected\" notify message.
> This message is protected by a keyed hash which uses a derivative of
> the pairwise key created during the key exchange. This keyed hash will
> be calculated over the KRB to provide tamper resistance.
>
> The typical KRB processing is outlined below. For this example assume
> the initiator is required to perform key recovery. The key recovery
> actions could be performed by the initiator, responder, or both.

1.  The ISAKMP Phase 1 exchange is performed as normal.

```{=html}
<!-- -->
```
1.  The initiator of the Phase 2 exchange sets the commit flag in the
    ISAKMP Header (HDR) sent at the start of the OAKLEY quick mode
    exchange. (The responder could also set the commit bit in the packet
    sent from responder to initiator.)

```{=html}
<!-- -->
```
1.  The exchange is completed and the key for IPSEC ESP is produced
    along with other keying material. The associated IPSEC SA cannot be
    used yet.

```{=html}
<!-- -->
```
1.  The initiator prepares the key recovery block and notification
    payload.

-   The inner contents of the key recovery block (KRB) are vendor
    specific but the outermost fields contain common information such as
    the ID of the key recovery agent. (Sarbari Gupta is developing the
    block format.)

```{=html}
<!-- -->
```
-   The type and length fields are prepended to the KRB. The type field
    is an IANA registered number indicating \"additional key management
    information.\"

```{=html}
<!-- -->
```
-   The key recovery block is placed into the Notification Data field of
    a notification payload. The notify message type is set to 16384
    (connected).

```{=html}
<!-- -->
```
-   The remainder of the notification payload fields are filled in just
    as they would be for a normal connected notification.

1.  The initiator computes the HASH over the notification payload per
    the ISAKMP spec. i.e., Hash=prf(SKEYID_a, M-ID, NOTIFY)

```{=html}
<!-- -->
```
1.  The initiator sends the authenticated (but NOT encrypted) packet to
    the responder. The packet has the form HDR, HASH, NOTIFY. The
    detailed structure of this packet is shown below.

> 1 2 3
>
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
> ISAKMP header
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ! Initiator !
>
> ! Cookie !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ! Responder !
>
> ! Cookie !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags !
>
> ! HASH = 8 ! ! ! INFORMATIONAL ! COMMIT = 0 !
>
> ! ! ! ! = 5 ! ENCRYPTION =0 !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ! Message ID !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ! Length !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Hash payload
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ! Next Payload ! RESERVED ! Payload Length !
>
> ! NOTIFY = 11 ! ! !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ! !
>
> \~ Hash Data \~
>
> ! !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Notification payload
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ! Next Payload ! RESERVED ! Payload Length !
>
> ! NONE = 0 ! ! !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ! Domain of Interpretation (DOI) !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ! Protocol-ID ! SPI Size ! Notify Message Type !
>
> ! ! ! CONNECTED = 16384 !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ! !
>
> \~ Security Parameter Index (SPI) \~
>
> ! !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ! Notification Data !
>
> ! Type ! Length !
>
> ! additional key management ! !
>
> ! information = TBD ! !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> \~ Key Recovery Block \~
>
> ! !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Informational exchange carrying a key recovery block
>
> The responder processes the informational exchange as follows.

1.  The standard informational exchange processing steps such as
    checking the ISAKMP header fields is performed.

```{=html}
<!-- -->
```
1.  The hash functions are performed as described in ISAKMP and Oakley.
    This validates the contents of the notification payload.

```{=html}
<!-- -->
```
1.  The notification payload is processed.

-   The connected (16384) is acknowledged by resetting the local commit
    flag.

```{=html}
<!-- -->
```
-   The notification data type is examined and found to be \"additional
    key management information.\" The responder does not process this,
    and silently discards it.

> The ISAKMP exchange is now complete, and the key for IPSEC ESP is
> placed into the IPSEC engine.
>
> There are several issues with this approach that must be worked out
> with the authors of the ISAKMP spec. (Unfortunately three of the
> authors are from the Government and the fourth is from Terisa Systems.
> None are members of the key recovery alliance.) These issues are
> identified in the summary.
>
> **4. SUMMARY**
>
> The KRA technical committee needs to provide feedback on this approach
> and determine if it is acceptable. If it is, we must work the
> following issues:

1.  Work with IANA to reserve the required number for the ISAKMP
    notification data type = \"additional key management information.\"
    This number will inform the receiving ISAKMP implementation and law
    enforcement that the key material has been placed on the wire in a
    KRB.

```{=html}
<!-- -->
```
1.  We must also work with the ISAKMP authors to ensure that the
    specification supports this approach. Specific allowances that need
    to be written into the spec are:

-   Implementations MUST accept notification payloads which are not
    encrypted even if an ISAKMP SA has been established. Subsection 4.8
    of the February 21, 1997 spec states \"Once an ISAKMP SA has been
    established, the Informational Exchange MUST be transmitted under
    the protection provided by the ISAKMP SA.\" We can argue that we are
    protecting the integrity but not the confidentiality using the
    ISAKMP SA. Daniel Harkins, an ISAKMP author, agrees that integrity
    is required. We must convince the ISAKMP authors that informational
    exchanges which are authenticated but not encrypted should be
    accepted.

```{=html}
<!-- -->
```
-   Implementation MUST silently discard Notification Data contained in
    a Notification Payload if the Notification Data type is not
    recognized; i.e., when an ISAKMP implementation receives
    notification data of type \"additional key management information,\"
    it discards it.

```{=html}
<!-- -->
```
-   The commit bit MAY be set by either or both parties in an ISAKMP
    exchange.

> If we can resolve these issues, we have a reasonable approach for key
> recovery in ISAKMP.
>
> **IP Security (IPSec)**

-   IP Security Architecture

```{=html}
<!-- -->
```
-   RFC 1825 (August 95)

```{=html}
<!-- -->
```
-   Defines two mechanisms for cryptographic protection of IP datagrams

```{=html}
<!-- -->
```
-   Authentication Header (AH)

```{=html}
<!-- -->
```
-   RFC 1826 (August 95)

```{=html}
<!-- -->
```
-   Integrity and authentication without confidentiality for IP
    datagrams

> +\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--+
>
> \| IP-HDR \| AUTH-HDR \| UPPER-PROTOCOL \|
>
> +\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--+
>
> **IPSec (Cont'd)**

-   Encapsulating Security Payload (ESP)

```{=html}
<!-- -->
```
-   RFC 1827 (August 95)

```{=html}
<!-- -->
```
-   Integrity, authentication, and confidentiality for IP datagrams

```{=html}
<!-- -->
```
-   Alone, in combo with AH, or nested

```{=html}
<!-- -->
```
-   Host-host, GW-GW, host-GW

```{=html}
<!-- -->
```
-   Two modes:

```{=html}
<!-- -->
```
-   Tunnel mode

> +\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--+
>
> \| IP-HDR \| PROTECTED-IP-DATAGRAM \|
>
> +\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--+

-   Transport mode

> +\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--+
>
> \| IP-HDR \| ESP-HDR \| PROTECTED-UPPER-PROTOCOL \|
>
> +\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--+
>
> **IPSec Revisions**

-   New Internet Drafts

```{=html}
<!-- -->
```
-   draft-ietf-ipsec-arch-sec-01.txt (??)

```{=html}
<!-- -->
```
-   draft-ietf-ipsec-esp-v2-00.txt (July 97)

```{=html}
<!-- -->
```
-   draft-ietf-ipsec-auth-header-01.txt (July 97)

```{=html}
<!-- -->
```
-   New ESP Draft

```{=html}
<!-- -->
```
-   More complete framework/context for ESP

```{=html}
<!-- -->
```
-   Define fields previously defined in transform docs

```{=html}
<!-- -->
```
-   I.e., authentication (and anti-replay) information (optional),
    padding, and next protocol

```{=html}
<!-- -->
```
-   Minimize combinatorial explosion of transforms

```{=html}
<!-- -->
```
-   Little-to-no impact on key recovery approach Key Recovery Header
    (KRH)

```{=html}
<!-- -->
```
-   New, third mechanism for key recovery

```{=html}
<!-- -->
```
-   MAY follow AH and MUST precede ESP header

```{=html}
<!-- -->
```
-   MAY be in an authenticated packet with critical Upper Protocol
    information

```{=html}
<!-- -->
```
-   Requires IP Protocol Number from IANA

> +\-\-\-\-\-\-\--+\-\-\--+\-\-\-\--+\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--+
>
> \| IP-HDR \| AH \| KRH \| ESP-HDR \| PROTECTED-UPPER-PROTOCOL \|
>
> +\-\-\-\-\-\-\--+\-\-\--+\-\-\-\--+\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--+
>
> \^\^\^\^\^
>
> **KRH Format**

-   Modeled after Authentication Header (AH)

> +\-\-\-\-\-\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\--+
>
> \| Next Header \| Length \| RESERVED \|
>
> +\-\-\-\-\-\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\--+
>
> \| Security Parameter Index \|
>
> +\-\-\-\-\-\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\--+
>
> \| \|
>
> \+ Key Recovery Block (variable number of 32-bit words) +
>
> \| \|
>
> +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--+
>
> **KRH Fields**

-   Next Header

```{=html}
<!-- -->
```
-   8 bits; identifies next payload after KRH; values are set of IP
    Protocol Numbers defined by IANA in STD-2

```{=html}
<!-- -->
```
-   Length

```{=html}
<!-- -->
```
-   8 bits; length of KRB in 32-bit words

```{=html}
<!-- -->
```
-   Security Parameter Index (SPI)

```{=html}
<!-- -->
```
-   32 bits; identifies, along with Destination Address (DA), Security
    Association (SA) for datagram; values 1-255 reserved by IANA for
    future use

```{=html}
<!-- -->
```
-   Key Recovery Block (KRB)

```{=html}
<!-- -->
```
-   variable (32-bit words); key recovery information using Common Key
    Recovery Block format; padding issues