R. Moskowitz, ICSA, Inc. Internet Draft Document: June 1999 ESP Encryption support in HIP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This memo describes a method to enable encryption in ESP [ESP] by using the Host Identity Payload, HIP [HIP]. Two initial datagrams that use HIP to authenticate a Diffie-Hellman exchange are sufficient to establish the keying material for ESP. Further information on the other components necessary for ESP implementations is provided by [Thayer97a]. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. 3. Introduction HIP is designed to provide a low overhead authentication of datagrams. It uses IPsec AH [AH] and ESP with NULL [ESP NULL] encryption for the actual authentication format. Since each datagram is authenticated, HIP can include an ephemeral Diffie- Moskowitz 1 ESP Encryption support in HIP June 1999 Hellman key and thus establish a Kij KEYMAT that ESP can use for encryption. This is not a replacement for IKE based KEYMAT negotiation. HIP lacks identity protection (except where the identity is ANONYMOUS), and lacks the Security Association granularity provided by IKE. However, in certain cases, like in MALLOC this is not an issue, and the lightweight nature of HIP makes it the a valuable addition to IPsec. 4. Basic Protocol flow At anytime within a HIP authenticated peer-to-peer communication, one system can initiate encryption. This is done by including an ephemeral Diffie-Hellman public key, along with an encryption proposal in the payload portion of the HIP header. Since this first packet is not encrypted (but is authenticated), there might be a need to send an 'uninteresting' datagram, like an ICMP ECHO. This could work well with the simple response approach. There are two different actions that the responder can use. The simple case is to include its own ephemeral Diffie-Hellman public key, along with its specific encryption proposal (much like in IKE Phase II) in the payload portion of the HIP header. It this point, the initiator can now use an ESP wrapper to encrypt its next datagram. It is also possible for the responder to immediately encrypt its payload. This is down by nesting the encrypted ESP wrapper within the HIP authenticated AH or ESP NULL wrapper. The initiator can then drop the AH or ESP NULL wrapper on its next datagram. At any time, one system can fall back to authentication mode only using Auth DSS [AUTH DSS]. The other system MUST also fall back to authentication mode only as well. Encryption mode can be reestablished by repeating the exchange with new Diffie-Hellman values. The old values SHOULD NOT be reused. 4.1. Two packet encryption with IPsec tunnel mode Initiator Datagram: IP||HIP{D-H key||encrypt proposal}||[AH|ESP NULL]||IP Datagram Responder Datagram: IP||HIP{D-H key||encrypt proposal}||[AH|ESP NULL]||ESP||IP Datagram Follow-on Datagram: IP||HIP||ESP||IP Datagram Moskowitz 2 ESP Encryption support in HIP June 1999 4.2. Three packet encryption with IPsec tunnel mode Initiator Datagram: IP||HIP{D-H key||encrypt proposal}||[AH|ESP NULL]||IP Datagram Responder Datagram: IP||HIP{D-H key||encrypt proposal}||[AH|ESP NULL]||IP Datagram Follow-on Datagram: IP||HIP||ESP||IP Datagram 4.3. Two or three packet encryption with IPsec transport mode These are the same as the tunnel mode, as shown above, except that the final wrapper is [TCP|UDP] Datagram. 4.4. Rekeying ESP with HIP There is no real rekeying function in HIP as there is in IKE. However, there are two approaches that can be implemented to force rekeying. The first, and crudest is to restart the HIP sequence number state machine. This will force a rekeying. The second approach is to first turn off encryption by sending an Authentication only HIP datagram, and then starting the HIP encryption negotiation. A third approach would be to send a new D-H payload while still encrypting. This has an advantage of not restarting the state machine, nor stopping encryption for any packets. In any case, the rekeying interval COULD be controlled by including lifetimes in the encryption proposal as is done in IKE Phase II. 5. HIP Payloads to support enabling IPsec encryption. Two additional payload formats are needed from the basic HIP formats. One to carry the Diffie-Hellman keys, and one to carry the encryption proposal. 5.1. Diffie-Hellman Keys in the HIP payload Moskowitz 3 ESP Encryption support in HIP June 1999 Diffie-Hellman keys are carried in the HIP payload in DNS D-H RR [DH RR]. Note that the very first HIP payload can thus easily contain both the DNS DSA RR and the D-H RR. So that encryption can be enabled without any earlier authentication only datagrams. 5.2. Encryption proposals in the HIP payload At this time, there is no clear solution to formatting encryption proposals within the HIP payload. The simplest approach may be to define a DNS RR for ISAKMP [ISAKMP] payloads, and use the same ISAKMP payloads used by IKE Phase II. It may be desirable to find some other appropriate RR to use so that HIP only implementations do not need to include any ISAKMP logic. 6. IPsec values for encryption with HIP 6.1. Security Parameters Index (SPI) The SPI for IPsec is still 2 as in authentication only HIP. This is true even when there are two IPsec headers. 6.2. Sequence Number There is no change in the handling of the Sequence Number field when enabling encryption. When there are two IPsec headers, they will have the same Sequence Number. This provides for Sequence Number continuity as the nature and number of IPsec headers changes so that the Sequence Number state machine can be maintained as described in the HIP document [HIP]. 7. Security Considerations Encryption enabled by HIP has at best a rudimentary rekeying capability. This lack of reliably implemented rekeying must be considered in the use of this encryption approach. 7.1. Changes to the ICV for AH and ESP with HIP For the Integrity Check Value Calculation in AH and ESP, HIP is treated as immutable in transit and MUST be included in the ICV. Without this, at substitution attack is possible against HIP. 8. IANA Considerations There are no additional IANA Considerations beyond those in IPsec and HIP. Moskowitz 4 ESP Encryption support in HIP June 1999 9. References [HIP], Moskowitz, R., "The Host Identity Payload", draft-ietf- moskowitz-HIP-00.txt, May 1999. [ESP], Kent, S., and R. Atkinson, "IP Encapsulating Security Payload", RFC 2406, November 1998. [AH], Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [Thayer97a], Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998. [RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997 [ESP NULL], R. Glenn and Kent, S., "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998. [ISAKMP], Maughan D., "Internet Security Association and Key Management Protocol", RFC 2408, November 1998. [AUTH_DSS], Moskowitz, R., "The Use of DSS within ESP and AH", draft-ietf-moskowitz-auth-dss-00.txt, May 1999. [DH_RR], Eastlake, D., "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", RFC 2539, March 1999. 10. Acknowledgments Initial conversations with Baiju Patel revealed the basic flow to switch from the basic Auth DSS of HIP to an HMAC thus allowing for encryption. Further conversations with Hugh Daniels resulted in the current architecture. 11. Author's Addresses Robert Moskowitz ICSA, Inc. 1200 Walnut Bottom Rd. Carlisle, PA 17013 Email: rgm@icsa.net Moskowitz 5