# **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 the
> protocol 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.** Certification shall be determined through the
> functionality of, and 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. 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 to provide 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 describe 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 body shall include the following:**

-   **Originator identity**

-   **Recipient identity**

-   **Current date and time**

-   **Date and time of encrypted key/data capture**

-   **Key recovery block**

-   **Optional: subject passphrase**

-   **Optional: MIME formatted encrypted data**

> **5.2.1 Individual items within the request transaction body shall be
> delimited by blank lines.**
>
> **Originator-id: \<**identifying information\>
>
> **Recipient-id:** **\<**identifying information\>
>
> **Date-Time:** \<date/time string\>
>
> **Capture-Time:** \<date/time string\>
>
> **KRB:** \<printably encoded recovery block\>
>
> **Passphrase:** \<subject authentication data\>
>
> **Encrypted-Data:** \<MIME encoded data\>
>
> **5.2.2 EXAMPLE: Key Recovery Request**

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

-   **KRA identity information**

-   **KRR identity information**

-   **Recipient identity**

-   **Current date and time**

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

-   **Printably encoded key**

-   **Optional: MIME formatted data**

    **5.3.1 Individual items within the response transaction body shall
    be delimited by blank lines.**

    **KRA-id: \<**identifying information\>

    **KRR-id: \<**identifying information\>

    **Recipient-id:** **\<**identifying information\>

    **Date-Time:** \<date/time string\>

    **Recovery-Time:** \<date/time string\>

    **DEK:** \<printably encoded encryption key\>

    **Data:** \<MIME encoded data\>

    **5.3.2 EXAMPLE: Key Recovery Response**

    ***[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* {#smime .unnumbered}

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* {#msp .unnumbered}

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* {#pem .unnumbered}

The Privacy Enhanced Mail (PEM) protocol provides encryption for
Internet electronic mail. PEM defines one encapsulation mechanism 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.

-   Allow interoperation of products from different vendors which have
    implemented different key recovery infrastructures.

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

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

-   *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

-   Identify Protection exchange

-   Authentication Only exchange

-   Aggressive exchange

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

2.  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.)

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

4.  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.)

-   The type and length fields are prepended to the KRB. The type field
    is an IANA registered number indicating \"additional key management
    information.\"

-   The key recovery block is placed into the Notification Data field of
    a notification payload. The notify message type is set to 16384
    (connected).

-   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)

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

2.  The hash functions are performed as described in ISAKMP and Oakley.
    This validates the contents of the notification payload.

3.  The notification payload is processed.

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

-   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. (Three of the authors are from
> the Government and the fourth is from Terisa Systems. Unfortunately,
> 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.

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

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

-   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

-   RFC 1825 (August 95)

-   Defines two mechanisms for cryptographic protection of IP datagrams

-   Authentication Header (AH)

-   RFC 1826 (August 95)

-   Integrity and authentication without confidentiality for IP
    datagrams

    +\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--+

    \| IP-HDR \| AUTH-HDR \| UPPER-PROTOCOL \|

    +\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--+

    **IPSec (Cont'd)**

-   Encapsulating Security Payload (ESP)

-   RFC 1827 (August 95)

-   Integrity, authentication, and confidentiality for IP datagrams

-   Alone, in combo with AH, or nested

-   Host-host, GW-GW, host-GW

-   Two modes:

-   Tunnel mode

    +\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--+

    \| IP-HDR \| PROTECTED-IP-DATAGRAM \|

    +\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--+

-   Transport mode

    +\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--+

    \| IP-HDR \| ESP-HDR \| PROTECTED-UPPER-PROTOCOL \|

    +\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--+

    **IPSec Revisions**

-   New Internet Drafts

-   draft-ietf-ipsec-arch-sec-01.txt (??)

-   draft-ietf-ipsec-esp-v2-00.txt (July 97)

-   draft-ietf-ipsec-auth-header-01.txt (July 97)

-   New ESP Draft

-   More complete framework/context for ESP

-   Define fields previously defined in transform docs

-   I.e., authentication (and anti-replay) information (optional),
    padding, and next protocol

-   Minimize combinatorial explosion of transforms

-   Little-to-no impact on key recovery approach Key Recovery Header
    (KRH)

-   New, third mechanism for key recovery

-   MAY follow AH and MUST precede ESP header

-   MAY be in an authenticated packet with critical Upper Protocol
    information

-   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

-   8 bits; identifies next payload after KRH; values are set of IP
    Protocol Numbers defined by IANA in STD-2

-   Length

-   8 bits; length of KRB in 32-bit words

-   Security Parameter Index (SPI)

-   32 bits; identifies, along with Destination Address (DA), Security
    Association (SA) for datagram; values 1-255 reserved by IANA for
    future use

-   Key Recovery Block (KRB)

-   variable (32-bit words); key recovery information using Common Key
    Recovery Block format; padding issues