One document matched: draft-moskowitz-hip-enc-00.txt

                     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