home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ipsec-inline-isakmp-00.txt < prev    next >
Text File  |  1996-11-26  |  18KB  |  509 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8. IPSEC Working Group                                      Bill Sommerfeld
  9. INTERNET-DRAFT                                           Hewlett Packard
  10. draft-ietf-ipsec-inline-isakmp-00.txt                      November 1996
  11.  
  12.  
  13.  
  14.  
  15.                Inline Keying within the ISAKMP Framework.
  16.                 <draft-ietf-ipsec-inline-isakmp-00.txt>
  17.  
  18.  
  19.  
  20.  
  21. STATUS OF THIS MEMO
  22.  
  23.    This document is an Internet-Draft.  Internet-Drafts are working
  24.    documents of the Internet Engineering Task Force (IETF), its areas,
  25.    and its working groups.  Note that other groups may also distribute
  26.    working documents as Internet-Drafts.
  27.  
  28.    Internet-Drafts are draft documents valid for a maximum of six months
  29.    and may be updated, replaced, or obsoleted by other documents at any
  30.    time.  It is inappropriate to use Internet-Drafts as reference
  31.    material or to cite them other than as ``work in progress.''
  32.  
  33.    To learn the current status of any Internet-Draft, please check the
  34.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  35.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  36.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  37.    ftp.isi.edu (US West Coast).
  38.  
  39.    Distribution of this document is unlimited.
  40.  
  41.    This particular Internet Draft is being published in order to focus
  42.    discussion on protocols for lightweight inline keying in the context
  43.    of ISAKMP/Oakley.  It is intended that this version will raise more
  44.    questions than it answers; there many ways to do inline keying and
  45.    the author does not pretend to have all the answers.  A future
  46.    version of this draft might become suitable for submission to the
  47.    IESG as a standards track protocol.
  48.  
  49. ABSTRACT
  50.  
  51.    The current proposal for IP-layer key management [ISAKMP, OAKLEY,
  52.    ISAOAK] has fairly high overhead.  Before a security association can
  53.    be established, at least one pair of messages need to be exchanged
  54.    between the communicating peers.  For efficiency, this suggests that
  55.    ISAKMP setup should be infrequent.  However, general principles of
  56.  
  57.  
  58.  
  59. Sommerfeld                 Expires 1 June 1997                  [Page 1]
  60.  
  61. Internet Draft    draft-ietf-ipsec-inline-isakmp-00.txt    November 1996
  62.  
  63.  
  64.    key management suggest that individual keys should be used as little
  65.    as practical and changed as frequently as possible.  Steve Bellovin
  66.    has suggested that, ideally, different security associations should
  67.    be used for each different transport-level connection[BADESP].
  68.  
  69.    This document discusses different ways of structuring a protocol to
  70.    permit this to happen with minimal overhead, both in round-trip delay
  71.    at connection setup, and in bandwidth once the connection is
  72.    established.
  73.  
  74.    Portions of this protocol have been inspired by SKIP, which is
  75.    fundamentally built around the concept of inline keying[SKIP].
  76.    SKIP's approach is burdened by the addition of an extra intermediate
  77.    header of perhaps 20 to 28 bytes to every protected packet,
  78.    essentially doubling the overhead of protected traffic compared with
  79.    ESP with manual keying.
  80.  
  81.    Ideally, an inline keying header would be used only until the desired
  82.    security association is established, at which point the peers will
  83.    fall back to pure ESP/AH.
  84.  
  85. DESCRIPTION OF THE PROTOCOL
  86.  
  87.    AH and ESP security associations are identified by a 32-bit
  88.    identifier known as an SPI, which is assigned by the receiving end of
  89.    the association.  This makes it difficult to create a new security
  90.    association at the request of a traffic originator without at least
  91.    one round trip.
  92.  
  93.    However, most packets are sent either in response to another packet,
  94.    or in the expectation that a response will be received.
  95.  
  96.    We can exploit this, by having the sender allocate an SPI for return
  97.    traffic, and include a message informing the recipient of it in the
  98.    first message.  The reponse to this message can also contain a return
  99.    SPI, so further packets in the conversation can be directed to the
  100.    appropriate security association for the conversation.
  101.  
  102.    There are at least two applications for this.  Hosts may wish to use
  103.    separate SPIs for separate transport-layer connections.  Similarly,
  104.    routers doing tunnel-mode ESP may wish to establish separate SPIs for
  105.    each active host-pair they tunnel.
  106.  
  107.    In the former case, for a typical TCP exchange, the in-band keying
  108.    headers would piggyback on the SYN and SYN/ACK packets, and would
  109.    then be absent from subsequent traffic.
  110.  
  111.    No explicit acknowledgement of the creation of the new SPI is needed;
  112.  
  113.  
  114.  
  115. Sommerfeld                 Expires 1 June 1997                  [Page 2]
  116.  
  117. Internet Draft    draft-ietf-ipsec-inline-isakmp-00.txt    November 1996
  118.  
  119.  
  120.    Use of the reply-SPI by the peer would (implicitly) acknowledge the
  121.    key change.
  122.  
  123.    No explicit retransmission of in-band-keying requests is needed; if
  124.    the upper-level protocol retransmits before the full SPI pair is
  125.    created, the inline keying header is included in the retransmission.
  126.  
  127. INLINE KEYING HEADER
  128.  
  129.    This version of the draft does not attempt to fully specify the
  130.    encoding of the inline keying header.  Comments on reasonable field
  131.    sizes, field orders, etc., are welcomed.
  132.  
  133.    Notation here is derived from the notation used in the Oakley draft.
  134.  
  135.    We assume the existance of a shared secret, sSPI between the
  136.    communicating parties, and a parent SPI corresponding to the shared
  137.    secret.  This can be established in a number of ways, which will be
  138.    discussed later.
  139.  
  140.    This protocol can be framed as a new sub-protocol of ESP, or else as
  141.    a new IP payload type as in SKIP.  Arguments for or against either
  142.    option are invited.  If the former option is used, one bit is needed
  143.    somewhere in the encoding to specify whether or not an inline keying
  144.    header is present in the packet.
  145.  
  146.    Header fields:
  147.  
  148.         parent-SPI
  149.         current-packet-nonce
  150.         payload-offset
  151.         next-payload
  152.         authenticator
  153.         sequence
  154.         spi-creation-fields:
  155.              reply-SPI
  156.              reply-SPI-scope
  157.              reply-SPI-lifetime
  158.              reply-SPI-nonce
  159.              reply-SPI-parameters
  160.              peer-SPI-nonce
  161.         <payload>
  162.  
  163.    Notes on the fields:
  164.  
  165.    Parent-SPI should be an already existing SPI from the sender to the
  166.    receiver.
  167.  
  168.  
  169.  
  170.  
  171. Sommerfeld                 Expires 1 June 1997                  [Page 3]
  172.  
  173. Internet Draft    draft-ietf-ipsec-inline-isakmp-00.txt    November 1996
  174.  
  175.  
  176.    Current-packet-nonce is a nonce used in the generation of the key
  177.    used to protect the current packet.
  178.  
  179.    If the parent-spi specifies encryption, all fields other than the
  180.    parent-SPI and the current-packet-nonce are encrypted.
  181.  
  182.    payload-offset indicates the start of the payload.
  183.  
  184.    next-payload is the payload type of the enclosed payload.
  185.  
  186.    payload is the enclosed payload.
  187.  
  188.    authenticator is a MAC of the inlike keying header plus payload; the
  189.    mac algorithm is specified by the parent SPI.
  190.  
  191.    sequence is a sequence number for replay detection; this might only
  192.    need a very small range (one byte?); conceivably this might be
  193.    included as a subfield of the current-packet-nonce.
  194.  
  195.    spi-creation-fields is a set of fields which tell the receiver how to
  196.    create an outbound SPI for reponses to the payload of this datagram.
  197.    This set includes:
  198.  
  199.    Reply-SPI is the number of an SPI created by the sender for responses
  200.    to this packet.
  201.  
  202.    Reply-SPI-scope indicates the scope of the reply SPI; exact encoding
  203.    is TBS and should probably be similar to the way the scope is handled
  204.    in [DOI].  The scope should be able to select among (at least) four
  205.    possible scopes: host-range, host, protocol, protocol+port.
  206.  
  207.    Reply-SPI-lifetime is the lifetime (exact encoding TBS), of the
  208.    newly-created SPI.  A similar encoding to the one used by [DOI]
  209.    should be used here.
  210.  
  211.    reply-SPI-parameters are other parameters of the newly created SPI,
  212.    including the algorithm, and any algorithm-specific parameters.  An
  213.    encoding similar to the one used by [DOI] should be used.
  214.  
  215.    Peer-spi-nonce is either all zeros, or the peer's reply-SPI-nonce.
  216.  
  217.    The key(s) used to protect this packet, including the payload, are
  218.    derived from
  219.  
  220.         prf (sSPI, current-TAG  | current-packet-nonce | parent-SPI)
  221.  
  222.    The key(s) associated with the newly-created SPI are derived from:
  223.  
  224.  
  225.  
  226.  
  227. Sommerfeld                 Expires 1 June 1997                  [Page 4]
  228.  
  229. Internet Draft    draft-ietf-ipsec-inline-isakmp-00.txt    November 1996
  230.  
  231.  
  232.         prf (sSPI, reply-TAG | peer-spi-nonce | reply-spi-nonce |
  233.              reply-SPI)
  234.  
  235.    current-TAG and reply-TAG are well-known constants, TBD.
  236.  
  237.    sSPI is the shared secret associated with the parent SPI.
  238.  
  239.    prf(a, b) is a pseudo-random function as in Oakley; the exact
  240.    function to use is a parameter of the parent SPI.
  241.  
  242.    It may be desirable to include other fields from the header in both
  243.    of the key-derivation hashes.
  244.  
  245. PACKET PROCESSING
  246.  
  247.    Some additional logic needs to be added to an implementation's
  248.    outbound and inbound policy engines.  As this protocol has not yet
  249.    been implemented, the following is necessarily vague; suggestions on
  250.    how to improve it are welcomed.
  251.  
  252.    When sending a packet, if there isn't a valid outbound SPI we want to
  253.    use to reach the peer, and we have reason to believe the peer accepts
  254.    inline keying headers, we look up the inbound SPI we want our peer to
  255.    use (or create it if it's nonexistant) and insert an in-band keying
  256.    header in the outbound packet.
  257.  
  258.    On the other hand, if there is a valid outbound SPI, we use it.  If
  259.    there isn't a valid inbound SPI for a response, we create the inbound
  260.    SPI we want to receive replies on and insert an in-band-keying header
  261.    in the outbound packet, then send it using the outbound SPI.
  262.  
  263.    If an inbound packet contains a valid in-band-keying header with a
  264.    reply SPI in it, we create an outbound SPI with the appropriate TTL,
  265.    and then process the rest of the packet.
  266.  
  267. PARENT SPI PARAMETERS
  268.  
  269.    The parent SPI needs the following parameters specified or
  270.    negotiated:
  271.     - a shared secret
  272.     - which pseudo-random function (prf) is used for key derivation.
  273.     - the algorithm used for encryption, and any algorithm-specific
  274.    parameters (other than the key).
  275.     - the algorithm used for authentication, and any algorithm-specific
  276.    parameters (other than the key).
  277.  
  278. ESTABLISHING THE PARENT SPI.
  279.  
  280.  
  281.  
  282.  
  283. Sommerfeld                 Expires 1 June 1997                  [Page 5]
  284.  
  285. Internet Draft    draft-ietf-ipsec-inline-isakmp-00.txt    November 1996
  286.  
  287.  
  288.    Since this scheme can only "spawn" new SPIs from old SPIs, how does
  289.    one establish the first SPI?
  290.  
  291.    There are several possible alternatives:
  292.  
  293.    Obviously, one of the ISAKMP exchanges could be used to establish the
  294.    parent SPI.
  295.  
  296.    Another alternative, very similar to SKIP, would be for a system to
  297.    publish a certificate containing a Diffie-Hellman public key, a "well
  298.    known" SPI, and at least the additional parent-SPI parameters listed
  299.    above.  The shared secret actually used in the inline-keying protocol
  300.    would depend on the source address of the packet.  It is not clear
  301.    whether this variation is of interest and is included only for
  302.    completeness.
  303.  
  304. ALTERNATIVES.
  305.  
  306.    An alternative scheme which may have somewhat higher overhead but
  307.    might be simpler to specify and implement may be to encapsulate
  308.    Oakley "quick mode" messages in the inline keying header in place of
  309.    the spi-creation-fields.  I have not fully investigated the
  310.    ramifications of this; additional sequencing or replay detection may
  311.    be needed in this case.
  312.  
  313.    This approach requires three messages (instead of two) before the
  314.    child SAs are established; also, the inline keying headers are likely
  315.    to be significantly larger.
  316.  
  317. MISCELLANEOUS ISSUES
  318.  
  319.    There are a number of miscellaneous problems which arise as a result
  320.    of constructing a protocol of this form.  None of them seem to be
  321.    particularly insurmountable.  These considerations are based on the
  322.    author's experience with vaguely similar security protocols.
  323.  
  324.   Interaction With MTU Discovery
  325.  
  326.    Because insertion of the inline keying header will change the size of
  327.    the packet, there are likely to be interactions between this protocol
  328.    and MTU discovery when the first packet triggering the creation of a
  329.    new SA pair is near maximum size.
  330.  
  331.    Several potential solutions come to mind:
  332.  
  333.    1) With some cooperation between layers, it may be possible to reduce
  334.    the amount of data in the outbound packet (this may be possible for
  335.    TCP; it's almost certainly not possible for other protocols).
  336.  
  337.  
  338.  
  339. Sommerfeld                 Expires 1 June 1997                  [Page 6]
  340.  
  341. Internet Draft    draft-ietf-ipsec-inline-isakmp-00.txt    November 1996
  342.  
  343.  
  344.    2) MTU discovery could be deferred, by sending the packet with DF
  345.    cleared.
  346.  
  347.    Neither of these seem really satisfactory; suggestions on how to
  348.    handle this case are welcomed.
  349.  
  350.   SPI expiration and clock skew.
  351.  
  352.    This section perhaps belongs as an appendix to the a future version
  353.    of the Internet DOI specification [DOI].
  354.  
  355.    Inline SPI's expire after a defined time.  Since relative timestamps
  356.    are used in the protocol, clocks synchronized in phase are not
  357.    assumed; however, some minimal accuracy in frequency is assumed.
  358.  
  359.    It is assumed here that SPI timestamps are maintained in absolute
  360.    form internally and converted to and from relative form only for use
  361.    over the network.
  362.  
  363.    The explicit expiration time of the SPI indicates the time after
  364.    which the sender should no longer send to that SPI.  The recipient
  365.    should still honor inbound packets to that SPI for an additional
  366.    grace period of:
  367.         K1 * MSL + K2 * nominal-lifetime
  368.    where "MSL" is the maximum lifetime of a packet in the network as in
  369.    TCP, "K1" is a fudge factor allowing some margin around MSL, and "K2"
  370.    is a fudge factor allowing for a difference in clock frequency
  371.    between systems.
  372.  
  373.    Proposed default values:
  374.         MSL: 120  (same as TCP)
  375.         K1: 2          (same as TCP)
  376.         K2: 1/32  (allow for ~3% frequency difference)
  377.    It may be useful for debugging purposes to allow these parameters to
  378.    be adjusted.
  379.  
  380.    With the above constants, a nominal 10-minute SPI would be valid for
  381.    about 14 minutes; and a nominal 2-hour SPI would be valid for
  382.    approximately 2 hours and 8 minutes.
  383.  
  384. EXAMPLE
  385.  
  386.    The following is a simplified example of the messages involved in
  387.    setting up a new SPI pair using inline keying.  A lot of detail has
  388.    been omitted to clarify the presentation.
  389.  
  390.    Assume per-connection inline keying is in use between two hosts A and
  391.    B, with a security association X existing from A to B.
  392.  
  393.  
  394.  
  395. Sommerfeld                 Expires 1 June 1997                  [Page 7]
  396.  
  397. Internet Draft    draft-ietf-ipsec-inline-isakmp-00.txt    November 1996
  398.  
  399.  
  400.    A wishes to establish a TCP connection to B.  Because per-connection
  401.    keying is in use, A would first create a new inbound SPI "Y", and
  402.    send:
  403.  
  404.         ESP [A-to-B, inline[N1, seq 0, Y], TCP [port 4352 to 21, SYN]]
  405.  
  406.    Upon receipt, B creates a new outbound SPI "Y", and a new inbound SPI
  407.    "Z", and hands off the TCP packet to its TCP.  It then responds with:
  408.  
  409.         ESP [Y, inline[N2, seq 0, Z], TCP [port 21 to 4352, SYN+ACK]]
  410.  
  411.    Upon receipt, A creates a new outbound SPI "Z".
  412.  
  413.    Receipt of a packet on spi Y acknowleges receipt of the inline-keying
  414.    message, so subsequent messages for this connection do not contain an
  415.    inline keying header, so A responds with:
  416.  
  417.         ESP [Z, TCP [port 4352 to 21, ACK, data1]]
  418.  
  419.    Similarly, B responds with:
  420.  
  421.         ESP [Y, TCP [port 21 to 4352, ACK, data2]]
  422.  
  423.    and the conversation would continue like this until the TCP
  424.    connection closed.
  425.  
  426. SECURITY CONSIDERATIONS
  427.  
  428.    This entire document concerns key management for the IP security
  429.    protocols.
  430.  
  431.    This protocol does not provide for Perfect Forward Secrecy by itself,
  432.    but if used in conjunction with ISAKMP, may provide a reasonable
  433.    engineering tradeoff between security and performance.
  434.  
  435.    As with Oakley's Quick Mode, this protocol can consume the entropy of
  436.    the shared secret[ISAOAK]. Implementors should take note of this fact
  437.    and be able to limit the number of inline-keying messages allowed per
  438.    shared secret.  This draft does not proscribe such a limit.
  439.  
  440. REFERENCES
  441.  
  442.    [BADESP]  Bellovin, S., "Problem Areas for the IP Security
  443.              Protocols", Proceedings of the Sixth Usenix UNIX security
  444.              symposium, July 1996 (available from
  445.              ftp://ftp.research.att.com/dist/smb/badesp.ps)
  446.  
  447.    [AH]      Atkinson, R., "IP Encapsulating Security Payload (ESP)",
  448.  
  449.  
  450.  
  451. Sommerfeld                 Expires 1 June 1997                  [Page 8]
  452.  
  453. Internet Draft    draft-ietf-ipsec-inline-isakmp-00.txt    November 1996
  454.  
  455.  
  456.              RFC1826, August 1995.
  457.  
  458.    [DOI]     Piper, D., "The Internet IP Security Domain Of
  459.              Interpretation for ISAKMP", version 1, draft-ietf-ipsec-
  460.              ipsec-doi-00.txt.
  461.  
  462.    [ESP]     Atkinson, R., "IP Encapsulating Security Payload (ESP)",
  463.              RFC1827, August 1995.
  464.  
  465.    [IPSEC]   Randall Atkinson, "Security Architecture for the Internet
  466.              Protocol", Internet Draft draft-ietf-ipsec-arch-sec-01.txt,
  467.              10 November 1996
  468.  
  469.    [ISAKMP]  Maughhan, D., Schertler, M., Schneider, M., and Turner, J.,
  470.              "Internet Security Association and Key Management Protocol
  471.              (ISAKMP)", version 6, draft-ietf-ipsec-isakmp-06.{ps,txt}.
  472.  
  473.    [ISAOAK]  Harkins, D., Carrel, D., "The resolution of ISAKMP with
  474.              Oakley", draft-ietf-ipsec-isakmp-oakley-02.txt.
  475.  
  476.    [OAKLEY]  Orman, H., "The Oakley Key Determination Protocol", version
  477.              1, draft-ietf-ipsec-oakley-01.txt.
  478.  
  479.    [SKIP]    Aziz, A., Markson, T., Prafullchandra, H., "Simple Key-
  480.              Management For Internet Protocols", draft-ietf-ipsec-
  481.              skip-07.txt.
  482.  
  483. AUTHOR'S ADDRESS:
  484.  
  485.    Bill Sommerfeld <sommerfeld@apollo.hp.com>
  486.    Hewlett Packard
  487.    300 Apollo Drive
  488.    Chelmsford MA 01824
  489.  
  490.    Telephone: +1 508 436 4352
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507. Sommerfeld                 Expires 1 June 1997                  [Page 9]
  508.  
  509.