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 Interoperable 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: Recipient-id: Date-Time: Capture-Time: KRB: Passphrase: Encrypted-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: KRR-id: Recipient-id: Date-Time: Recovery-Time: DEK: Data: 5.3.2 EXAMPLE: Key Recovery Response APPENDIX 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 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. 5. The initiator computes the HASH over the notification payload per the ISAKMP spec. i.e., Hash=prf(SKEYID_a, M-ID, NOTIFY) 6. 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 FIPS Interoperability Working Group #5 Key Recovery FIPS 2/98 1