Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_ietf_i/draft-ietf-ipsec-inline-isakmp-01.txt

Text File | 1997-03-27 | 19KB | 560 lines

IPSEC Working Group                                      Bill Sommerfeld
INTERNET-DRAFT                                           Hewlett Packard
draft-ietf-ipsec-inline-isakmp-01.txt                         March 1997




     Inline Keying within the ISAKMP Framework.
      <draft-ietf-ipsec-inline-isakmp-01.txt>




STATUS OF THIS MEMO

   This document is an Internet-Draft.  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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this document is unlimited.

   This particular Internet Draft is being published in order to focus
   discussion on protocols for lightweight inline keying in the context
   of ISAKMP/Oakley.  It is intended that this version will raise more
   questions than it answers; there many ways to do inline keying and
   the author does not pretend to have all the answers.  A future
   version of this draft might become suitable for submission to the
   IESG as a standards track protocol.

ABSTRACT

   The current proposal for IP-layer key management [ISAKMP, OAKLEY,
   ISAOAK] has fairly high overhead.  Before a security association can
   be established, at least one pair of messages need to be exchanged
   between the communicating peers.  For efficiency, this suggests that
   ISAKMP setup should be infrequent.  However, general principles of



Sommerfeld               Expires 1 October 1997                 [Page 1]

Internet Draft    draft-ietf-ipsec-inline-isakmp-01.txt      March 1997


   key management suggest that individual keys should be used as little
   as practical and changed as frequently as possible.  Steve Bellovin
   has suggested that, ideally, different security associations should
   be used for each different transport-level connection[BADESP].

   This document discusses a way of structuring a protocol to permit
   this to happen with minimal overhead, both in round-trip delay at
   connection setup, and in bandwidth once the connection is
   established.

   The general concept of inline or in-band keying here was inspired by
   SKIP[SKIP].  However, SKIP's approach is burdened by the addition of
   an extra intermediate header of perhaps 20 to 28 bytes to every
   protected packet, which doubles the bandwidth overhead of protected
   traffic compared with ESP with fixed keying.  In order to minimise
   the per-packet overhead, an inline keying header should be used only
   until the desired security association is established, at which point
   the peers will fall back to pure ESP/AH.

IN-BAND SECURITY ASSOCIATION SETUP

   AH and ESP security associations are identified by a 32-bit
   identifier known as an SPI, which is assigned by the receiving end of
   the association.  This makes it difficult to create a new security
   association at the request of a traffic originator without at least
   one round trip.

   However, most packets are sent either in response to another packet,
   or in the expectation that a response will be received.

   We can exploit this, by having the sender allocate an SPI for return
   traffic, and include a message informing the recipient of it in the
   first message.  The reponse to this message can also contain a return
   SPI, so further packets in the conversation can be directed to the
   appropriate security association for the conversation.

   There are at least two applications for this protocol.  Hosts may
   wish to use separate SPIs for separate transport-layer connections.
   Similarly, routers doing tunnel-mode ESP may wish to establish
   separate SPIs for each active host-pair they tunnel.

   In the former case, for a typical TCP exchange, the in-band keying
   headers would piggyback on the SYN and SYN/ACK packets, and would
   then be absent from subsequent traffic.

   No explicit acknowledgement of the creation of the new SPI is needed,
   as use of the reply-SPI by the peer would (implicitly) acknowledge
   the key change.



Sommerfeld               Expires 1 October 1997                 [Page 2]

Internet Draft    draft-ietf-ipsec-inline-isakmp-01.txt      March 1997


   No explicit retransmission of in-band-keying requests is needed; if
   the upper-level protocol retransmits before the full SPI pair is
   created, the inline keying header is included in the retransmission.

PACKET PROCESSING

   Some additional logic needs to be added to an implementation's
   outbound and inbound policy engines.  As this protocol has not yet
   been implemented, the following is necessarily vague; suggestions on
   how to improve it are welcomed.

   When sending a packet, if there isn't a valid outbound SPI we want to
   use to reach the peer, and we have reason to believe the peer accepts
   inline keying headers, we look up the inbound SPI we want our peer to
   use (or create it if it's nonexistant) and insert an in-band keying
   header in the outbound packet.

   On the other hand, if there is a valid outbound SPI, we use it.  If
   there isn't a valid inbound SPI for a response, we create the inbound
   SPI we want to receive replies on and insert an in-band-keying header
   in the outbound packet, then send it using the outbound SPI.

   If an inbound packet contains a valid in-band-keying header with a
   reply SPI in it, we create an outbound SPI with the appropriate TTL,
   and then process the rest of the packet.

PARENT SPI PARAMETERS

   The parent SPI must have the following parameters specified or
   negotiated:
    - a shared secret
    - the pseudo-random function (prf) to be used for key derivation.
    - the algorithm to be used for encryption, and any algorithm-specific
   parameters (other than the key).
    - the algorithm to be used for message integrity protection, and any
   algorithm-specific parameters (other than the key).

ESTABLISHING THE PARENT SPI.

   This scheme can only "spawn" new SPIs from old SPIs; therefore, there
   needs to be a way to establish the "parent" SPI.

   There are several possible alternatives:

   One of the ISAKMP exchanges could be used to establish the parent
   SPI.

   Another alternative, very similar to SKIP, would be for each system



Sommerfeld               Expires 1 October 1997                 [Page 3]

Internet Draft    draft-ietf-ipsec-inline-isakmp-01.txt      March 1997


   to publish a certificate containing a Diffie-Hellman public key, a
   "well known" SPI, and the additional parent-SPI parameters listed
   above.  The shared secret actually used in the inline-keying protocol
   would depend on the source address of the packet.  It is not clear
   whether this variation is of interest and is included only for
   completeness.

ENCODING OPTIONS

   There are a number of potential ways of encoding this protocol, with
   different advantages and disadvantages; at this point, it is not
   clear which way is best.  The primary areas of variability include:

    - how the SPI-creation message is framed

    - what is contained in the SPI-creation message

    - how the user payload "along for the ride" is protected.

   In order to minimize complexity, in the end, there should only be one
   answer for each of these questions.  Several requirements on the
   encoding exist:

    1) the SPI-creation message must be optional
    2) there should be some "cryptographic distance" between the three
   kinds of keys involved:
    - the key(s) used to authenticate and/or encrypt the user
payload which is along for the ride
    - the key(s) used to authenticate the SPI-creation message
    - the key(s) used by the newly-created reply SPI.
    3) there should be as much commonality in encoding between this
   protocol and the various sub-protocols of ESP and ISAKMP with similar
   functionality.

    4) the inline keying header should be small.

 FRAMING

   Three alternatives suggest themselves:

    - special-case encoding within an ESP transform, perhaps using a bit
   out of the pad length by mutual agreement between the communicating
   peers.

    - a new IP-layer protocol

    - use of the "IPv6 destination options" IP-layer protocol.




Sommerfeld               Expires 1 October 1997                 [Page 4]

Internet Draft    draft-ietf-ipsec-inline-isakmp-01.txt      March 1997


   Using a new IP-layer protocol seems cleanest, though there has been
   strong opposition to it from some implementors.  The use of the IPv6
   destination options protocol would limits the size of a single option
   to no more than 255 octets, which may be a significant constraint.

 REPLY-SPI-CREATION CONTENTS

   There are essentially two possibilities for the reply-SPI-creation
   message: either an encapsulated quick mode message, or a custom
   message simpler than, but similar to quick mode.

  Encapsulating ISAKMP/Oakley

   A simpler, but less efficient, alternative would be to encapsulate
   various ISAKMP/Oakley quick-mode messages as the reply-SPI-creation
   message.

  Custom Format

   Notation here is derived from the notation used in the Oakley draft.

   We assume the existance of a shared secret, sSPI between the
   communicating parties, and a parent SPI corresponding to the shared
   secret.  This can be established in a number of ways, which will be
   discussed later.

   Fields:

        reply-SPI
        reply-SPI-scope
        reply-SPI-lifetime
        reply-SPI-nonce
        reply-SPI-parameters
        peer-SPI-nonce

   spi-creation-fields is a set of fields which tell the receiver how to
   create an outbound SPI for reponses to the payload of this datagram.
   This set includes:

   Reply-SPI is the number of an SPI created by the sender for responses
   to this packet.

   Reply-SPI-scope indicates the scope of the reply SPI; exact encoding
   is TBS and should probably be similar to the way the scope is handled
   in [DOI].  The scope should be able to select among (at least) four
   possible scopes: host-range, host, protocol, protocol+port.

   Reply-SPI-lifetime is the lifetime (exact encoding TBS), of the



Sommerfeld               Expires 1 October 1997                 [Page 5]

Internet Draft    draft-ietf-ipsec-inline-isakmp-01.txt      March 1997


   newly-created SPI.  A similar encoding to the one used by [DOI]
   should be used here.

   reply-SPI-parameters are other parameters of the newly created SPI,
   including the algorithm, and any algorithm-specific parameters.  An
   encoding similar to the one used by [DOI] should be used.

   Peer-spi-nonce is either all zeros, or the peer's reply-SPI-nonce.

   The key(s) associated with the newly-created SPI are derived from:

        prf (sSPI, reply-TAG | peer-spi-nonce | reply-spi-nonce |
   reply-SPI)

   reply-TAG is a well-known constant, TBD.

   sSPI is the shared secret associated with the parent SPI.

   prf(a, b) is a pseudo-random function as in Oakley; the exact
   function to use is a parameter of the parent SPI.

   It may be desirable to include other fields from the header in both
   of the key-derivation hashes.

 KEYING OF THE USER PAYLOAD

   If the "parent" algorithm is judged to be sufficently strong, the
   initial user payload could simply be encrypted using the ESP in the
   parent SPI.  However, the use of inline keying seems to suggest a
   desire to segregate different communications under different keys.

   A extension to ESP suggests itself.  We can negotiate the addition of
   a "key generation nonce" to the cleartext part of the ESP header, and
   then generate the key for encrypting the ciphertext portion of the
   packet using a keyed hash of the shared secret and the nonce:

        prf (sSPI, current-packet-nonce | SPI | other)

   sSPI is the SPI's shared secret;

   current-packet-nonce is a 128-bit random value generated by the
   sender (ideally different for each packet).

   "SPI" is the numeric SPI value.

   "other" are any additional fields which might make sense to include
   in the key-generation hash.




Sommerfeld               Expires 1 October 1997                 [Page 6]

Internet Draft    draft-ietf-ipsec-inline-isakmp-01.txt      March 1997


MISCELLANEOUS ISSUES

   There are a number of miscellaneous problems which arise as a result
   of constructing a protocol of this form.  None of them seem to be
   particularly insurmountable.  These considerations are based on the
   author's experience with vaguely similar security protocols.

 Interaction With MTU Discovery

   Because insertion of the inline keying header will change the size of
   the packet, there are likely to be interactions between this protocol
   and MTU discovery when the first packet triggering the creation of a
   new SA pair is near maximum size.

   Several potential solutions come to mind:

   1) With some cooperation between layers, it may be possible to reduce
   the amount of data in the outbound packet (this may be possible for
   TCP; it's almost certainly not possible for other protocols).

   2) MTU discovery could be deferred, by sending the packet with DF
   cleared.

   Neither of these seem really satisfactory; suggestions on how to
   handle this case are welcomed.

 SPI expiration and clock skew.

   This section perhaps belongs as an appendix to the a future version
   of the Internet DOI specification [DOI].

   Inline SPI's expire after a defined time.  Since relative timestamps
   are used in the protocol, clocks synchronized in phase are not
   assumed; however, some minimal accuracy in frequency is assumed.

   It is assumed here that SPI timestamps are maintained in absolute
   form internally and converted to and from relative form only for use
   over the network.

   The explicit expiration time of the SPI indicates the time after
   which the sender should no longer send to that SPI.  The recipient
   should still honor inbound packets to that SPI for an additional
   grace period of:
        K1 * MSL + K2 * nominal-lifetime
   where "MSL" is the maximum lifetime of a packet in the network as in
   TCP, "K1" is a fudge factor allowing some margin around MSL, and "K2"
   is a fudge factor allowing for a difference in clock frequency
   between systems.



Sommerfeld               Expires 1 October 1997                 [Page 7]

Internet Draft    draft-ietf-ipsec-inline-isakmp-01.txt      March 1997


   Proposed default values:
        MSL: 120  (same as TCP)
        K1: 2          (same as TCP)
        K2: 1/32  (allow for ~3% frequency difference)
   It may be useful for debugging purposes to allow these parameters to
   be adjusted.

   With the above constants, a nominal 10-minute SPI would be valid for
   about 14 minutes; and a nominal 2-hour SPI would be valid for
   approximately 2 hours and 8 minutes.

EXAMPLE

   The following is a simplified example of the messages involved in
   setting up a new SPI pair using inline keying.  A lot of detail has
   been omitted to clarify the presentation.

   Assume per-connection inline keying is in use between two hosts A and
   B, with a security association X existing from A to B.

   A wishes to establish a TCP connection to B.  Because per-connection
   keying is in use, A would first create a new inbound SPI "Y", and
   send:

        ESP [A-to-B, inline[N1, seq 0, Y], TCP [port 4352 to 21, SYN]]

   Upon receipt, B creates a new outbound SPI "Y", and a new inbound SPI
   "Z", and hands off the TCP packet to its TCP.  It then responds with:

        ESP [Y, inline[N2, seq 0, Z], TCP [port 21 to 4352, SYN+ACK]]

   Upon receipt, A creates a new outbound SPI "Z".

   Receipt of a packet on spi Y acknowleges receipt of the inline-keying
   message, so subsequent messages for this connection do not contain an
   inline keying header, so A responds with:

        ESP [Z, TCP [port 4352 to 21, ACK, data1]]

   Similarly, B responds with:

        ESP [Y, TCP [port 21 to 4352, ACK, data2]]

   and the conversation would continue like this until the TCP
   connection closed.

SECURITY CONSIDERATIONS




Sommerfeld               Expires 1 October 1997                 [Page 8]

Internet Draft    draft-ietf-ipsec-inline-isakmp-01.txt      March 1997


   This entire document concerns key management for the IP security
   protocols.

   This protocol does not provide for Perfect Forward Secrecy by itself,
   but if used in conjunction with ISAKMP, may provide a reasonable
   engineering tradeoff between security and performance.

   As with Oakley's Quick Mode, this protocol can consume the entropy of
   the shared secret[ISAOAK]. Implementors should take note of this fact
   and be able to limit the number of inline-keying messages allowed per
   shared secret.  This draft does not proscribe such a limit.

REFERENCES

   [BADESP]  Bellovin, S., "Problem Areas for the IP Security
   Protocols", Proceedings of the Sixth Usenix UNIX security
   symposium, July 1996 (available from
   ftp://ftp.research.att.com/dist/smb/badesp.ps)

   [AH]      Atkinson, R., "IP Encapsulating Security Payload (ESP)",
   RFC1826, August 1995.

   [DOI]     Piper, D., "The Internet IP Security Domain Of
   Interpretation for ISAKMP", version 1, draft-ietf-ipsec-
   ipsec-doi-00.txt.

   [ESP]     Atkinson, R., "IP Encapsulating Security Payload (ESP)",
   RFC1827, August 1995.

   [IPSEC]   Randall Atkinson, "Security Architecture for the Internet
   Protocol", Internet Draft draft-ietf-ipsec-arch-sec-01.txt,
   10 November 1996

   [ISAKMP]  Maughhan, D., Schertler, M., Schneider, M., and Turner, J.,
   "Internet Security Association and Key Management Protocol
   (ISAKMP)", version 6, draft-ietf-ipsec-isakmp-06.{ps,txt}.

   [ISAOAK]  Harkins, D., Carrel, D., "The resolution of ISAKMP with
   Oakley", draft-ietf-ipsec-isakmp-oakley-02.txt.

   [OAKLEY]  Orman, H., "The Oakley Key Determination Protocol", version
   1, draft-ietf-ipsec-oakley-01.txt.

   [SKIP]    Aziz, A., Markson, T., Prafullchandra, H., "Simple Key-
   Management For Internet Protocols", draft-ietf-ipsec-
   skip-07.txt.

AUTHOR'S ADDRESS:



Sommerfeld               Expires 1 October 1997                 [Page 9]

Internet Draft    draft-ietf-ipsec-inline-isakmp-01.txt      March 1997


   Bill Sommerfeld <[e-mail]>
   Hewlett Packard
   300 Apollo Drive
   Chelmsford MA 01824

   Telephone: [phone]













































Sommerfeld               Expires 1 October 1997                [Page 10]