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-revised-enc-mode-00.txt < prev    next >
Text File  |  1997-05-06  |  15KB  |  370 lines
  1.  
  2.  
  3. IPSEC Working Group                       R. Canetti, P. Cheng, H. Krawczyk 
  4. INTERNET-DRAFT                                IBM Research and the Technion
  5. draft-ietf-ipsec-revised-enc-mode-00.txt                         April 1997
  6. Expire in six months
  7.  
  8.  
  9.                A revised encryption mode for ISAKMP/Oakley
  10.                <draft-ietf-ipsec-revised-enc-mode-00.txt>
  11.  
  12.  
  13.                           Status of this Memo
  14.  
  15.    This document is an Internet Draft. Internet Drafts are working
  16.    documents of the Internet Engineering Task Force (IETF), its areas,
  17.    and working groups.  Note that other groups may also distribute
  18.    working documents as Internet Drafts.
  19.  
  20.    Internet Drafts are draft documents valid for a maximum of six months
  21.    and may be updated, replaced, or obsoleted by other documents at any
  22.    time. It is inappropriate to use Internet Drafts as reference
  23.    material or to cite them other than as "work in progress."
  24.  
  25.    To learn the current status of any Internet Draft, please check the
  26.    "1id-abstracts.txt" listing contained in the Internet Drafts Shadow
  27.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  28.    munnari.oz.au (Australia), ds.internic.net (US East Coast), or
  29.    ftp.isi.edu (US West Coast).
  30.  
  31.  
  32.  
  33.    1. Abstract
  34.  
  35.    The ISAKMP/Oakley document [HC97] describes a proposed standard for 
  36.    using the Oakley Key Exchange Protocol in conjunction with ISAKMP to 
  37.    obtain authenticated and secret keying material for use with ISAKMP, 
  38.    and for other security associations such as AH and ESP for the IETF 
  39.    IPsec DOI.
  40.  
  41.    The public-key encryption method of carrying out Phase 1 of the key
  42.    exchange in the ISAKMP/Oakley document requires two public key 
  43.    encryption and decryption operations from both the Initiator and 
  44.    the Responder. The present document describes a small modification 
  45.    to this method. The resulting method requires only one public key 
  46.    encryption and decryption operation from each party, while maintaining 
  47.    (and even improving on) the strong security properties of the 
  48.    ISAKMP/Oakley public-key encryption mode.    
  49.  
  50.    Remark: This document is NOT self-contained. It uses notation and 
  51.    definitions of [HC97]. It is best read in conjunction with [HC97].
  52.  
  53. Canetti, Cheng, Krawczyk                                           [Page i]
  54.  
  55. INTERNET DRAFT                                             April 1997
  56.  
  57.  
  58.    2. Introduction
  59.  
  60.    The ISAKMP/Oakley  protocol [HC97] defines three alternative methods of 
  61.    carrying out Phase 1 of the key exchange. Two of these methods are usable 
  62.    by parties that do not already share a secret key. These are the Signature
  63.    Method (Section 5.1 in [HC97]) and the Encryption Method (Section 5.2
  64.    in [HC97]).
  65.  
  66.    The Encryption Method enjoys several significant advantages over the 
  67.    Signature Method. These advantages are sketched in Section 4.
  68.    However, in the ISAKMP/Oakley draft the Encryption Method requires 
  69.    TWO public key encryption and decryption operations for each party. 
  70.    This is unnecessarily expensive. (In weak processors the extra 
  71.    exponentiation may have a significantly adverse effect in performance.) 
  72.  
  73.    This document describes a simple modification of the ISAKMP/Oakley
  74.    Encryption Method. The resulting method enjoys the same security 
  75.    advantages, and requires only ONE public key encryption and decryption 
  76.    operation for each party. This method, called the Revised Encryption 
  77.    Method, is presented as an alternative method to the ISAKMP/Oakley 
  78.    Encryption Method. In fact, the revised method enjoys even additional 
  79.    security advantages on top of the ISAKMP/Oakley Encryption Method, 
  80.    as elaborated below.
  81.  
  82.    The change from the ISAKMP/Oakley Encryption Method is basically as 
  83.    follows. There, each party's identity and nonce are encrypted via 
  84.    TWO separate applications of the public-key encryption algorithm. 
  85.    (In fact, if the party's identity is long then this may require 
  86.    additional applications of the public-key encryption algorithm.) 
  87.  
  88.    In the Revised Encryption Method the nonce is still encrypted
  89.    using the public-key encryption algorithm. However, 
  90.    the sending party's identity (and also the certificate, if it is 
  91.    sent) is encrypted via symmetric encryption (e.g. DES), with a key 
  92.    derived from the nonce. This solution adds no significant complexity to 
  93.    the implementation and saves a costly long (RSA or other) exponentiation.
  94.    In addition, the Key Exchange payload (ie. the DH challenges) is also
  95.    encrypted using the same derived key. This provides additional protection
  96.    against cryptanalysis of the DH exchange.
  97.    
  98.    The Revised Encryption mode has another advantage. The (optional)
  99.    Certificate payload is also encrypted using the same derived key. 
  100.    Consequently anonymity is preserved even if the certificate is sent 
  101.    as part of the exchange. 
  102.  
  103.    The rest of this document is organized as follows. In Section 3
  104.    the Revised Encryption Method is described. The description is 
  105.    written in a way so that Section 3 can be read as a replacement to 
  106.    Section 5.2 in [HC97]. Section 4 discusses some security advantages 
  107.    of the Encryption Method relative to the Signature method. 
  108.    (These advantages are shared by the Revised Encryption Method.)
  109.    Appendix A holds the authentication method value of the new method 
  110.    (see ISAKMP [MSST96] and Appendix A of [CH97]). 
  111.  
  112. Canetti, Cheng, Krawczyk                                           [Page 1]
  113.  
  114. INTERNET DRAFT                                             April 1997
  115.  
  116.  
  117.    3. The new method: Revised Encryption Method of Oakley Phase 1 
  118.  
  119.    Using public key encryption to authenticate the exchange, the
  120.    ancillary information exchanged is encrypted nonces. Each party's
  121.    ability to reconstruct a hash (proving that the other party decrypted
  122.    the nonce) authenticates the exchange.
  123.  
  124.    In order to perform the public key encryption, the initiator must
  125.    already have the responder's public key. In the case where a party
  126.    has multiple public keys, a hash of the certificate of the initiator 
  127.    used to encrypt the ancillary information is passed as part of the
  128.    third message. In this way the responder can determine which
  129.    corresponding private key to use to decrypt the encrypted payloads
  130.    and identity protection is retained.
  131.  
  132.    The nonces are encrypted with the other party's public key.
  133.    Only the body of the payload is encrypted, the payload header is
  134.    left in the clear. The Key Exchange payloads (KE) and the identities 
  135.    of the parties (IDii and IDir) are encrypted with the negotiated 
  136.    symmetric encryption algorithm (e.g DES), using a key derived from 
  137.    the nonce. If the Initiator's certificate is passed from Initiator to 
  138.    Responder then, for anonymity, the certificate is also encrypted 
  139.    under the same key.
  140.    
  141.    That is, Phase 1 (Main Mode) is defined as follows.
  142.  
  143.  
  144.           Initiator                        Responder
  145.          -----------                      -----------
  146.           HDR, SA                   -->
  147.                                     <--    HDR, SA
  148.           HDR, [ HASH(1), ]
  149.             <Ni>PubKey_r            -->
  150.             <KE>Ke_i 
  151.             <IDii>Ke_i
  152.             [<Cert-I>Ke_i]
  153.                                     <--  HDR, <Nr>PubKey_i
  154.                                              <KE>Ke_r
  155.                                              <IDir>Ke_r
  156.           HDR*, HASH_I              -->
  157.                                     <--    HDR*, HASH_R
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166. Canetti, Cheng, Krawczyk                                           [Page  2]
  167.  
  168. INTERNET DRAFT                                             April 1997
  169.  
  170.  
  171.  
  172.    HASH(1) is a hash (using the negotiated hash function) of the 
  173.    responder's certificate which the initiator is using to encrypt 
  174.    the nonce.
  175.  
  176.    The notation <...>PubKey refers to public key encryption
  177.    (e.g.  using the RSA algorithm) while the notation <...>Ke
  178.    refers to encryption under the negotiated symmetric cipher.
  179.    The keys for the symmetric cipher are derived as follows.
  180.    First, derive the values Ne_i and Ne_r:
  181.  
  182.          Ne_i = prf(Ni, CKY-I)
  183.          Ne_r = prf(Nr, CKY-R)
  184.  
  185.    Next, the keys Ke_i and Ke_r are derived from Ne_i and Ne_r,
  186.    respectively, in the way described in Appendix B of [HC97].
  187.    That is, to derive Ke_i run the procedure described in Appendix B of
  188.    [HC97], where SKEYID_e is replaced by Ne_i. To derive Ke_r run the
  189.    procedure described in Appendix B of [HC97], where SKEYID_e is 
  190.    replaced by Ne_r. 
  191.  
  192.    For completeness, we detail the  procedure for deriving Ke_i.
  193.    Ke_r is derived analogously. If the desired length of Ke_i is 
  194.    at most the length of Ne_i then Ke_i is the sufficient number 
  195.    of most significant bits of Ne_i. If the desired length of Ke_i 
  196.    exceeds the length of Ne_i then more bits are generated by applying 
  197.    the prf with Ne_i as the key and a byte of 0 as the input. 
  198.    The output of the prf is fed back into itself until sufficient 
  199.    number of bits are generated. For example, if the output of prf 
  200.    is 128-bit long and Ne_i needs to be 320-bit long, then Ne_i is 
  201.    the most significant 320 bits of K, where K = K1 | K2 | K3  and
  202.  
  203.            K1 = prf(Ne_i, 0)   
  204.            K2 = prf(Ne_i, K1)
  205.            K3 = prf(Ne_i, K2)
  206.  
  207.    Note that the values of Ke_i and Ke_r are ephemeral and discarded 
  208.    after this use. 
  209.  
  210.  
  211. Canetti, Cheng, Krawczyk                                           [Page  3]
  212.  
  213. INTERNET DRAFT                                             April 1997
  214.  
  215.    If CBC mode is used for the symmetric encryption then the 
  216.    initialization vectors (IV) are set as follows. The IV for 
  217.    encrypting KE is set to 0. The IV for encrypting IDii (resp., IDir)   
  218.    is the last ciphertext block of <KE>Ke_i (resp., <KE>Ke_r). 
  219.    The IV for encrypting the certificate 
  220.    is the last ciphertext block of <IDii>Ke_i (resp., <IDir>Ke_r).
  221.    Encrypted payloads are padded up to the nearest block 
  222.    size. All padding bytes, except for the last one, contain 0x00. 
  223.    The last byte of the padding contains the number of the padding 
  224.    bytes use, excluding the last one.
  225.    Note that this means that there will always be padding.
  226.    Note also that the IV chaining method used here implies that KE,
  227.    the ID and the certificate have to be encrypted (and decrypted) in 
  228.    that order.
  229.  
  230.    When a Certificate payload is sent in the context of
  231.    the Revised Encryption Method, it MUST be encrypted in the manner
  232.    described above.
  233.  
  234.  
  235.      Oakley Aggressive Mode in conjunction with the Revised Encryption 
  236.      Method is described as follows (notation is as described above):
  237.  
  238.           Initiator                        Responder
  239.          -----------                      -----------
  240.           HDR, SA, [ HASH(1),] 
  241.             <Ni>Pubkey_r,
  242.             <KE>Ke_i  
  243.             <IDii>Ke_i               -->
  244.             [<Cert-I>Ke_i]
  245.                                            HDR, SA, <Nr>PubKey_i,
  246.                                                 <KE>Ke_r
  247.                                     <--         <IDir>Ke_r, HASH_R
  248.           HDR, HASH_I               -->
  249.  
  250.  
  251.  
  252.    RSA encryption MUST be encoded in PKCS #1 format. The payload length
  253.    is the length of the entire encrypted payload plus header. The PKCS
  254.    #1 encoding allows for determination of the actual length of the
  255.    cleartext payload upon decryption.
  256.  
  257.  
  258.  
  259. Canetti, Cheng, Krawczyk                                           [Page 4]
  260.  
  261. INTERNET DRAFT                                             April 1997
  262.  
  263.    4. Security Considerations 
  264.    ==========================
  265.  
  266.    In this section we sketch the advantages of authentication by 
  267.    public-key encryption, as opposed to authentication by signature.
  268.    First, in the Encryption mode an attacker has to break BOTH the
  269.    the public key encryption in use (e.g. RSA) and DH exchange
  270.    in order to learn the agreed key. In the Signature Mode breaking the
  271.    DH exchange is sufficient. This is a substantial security advantage
  272.    in a scenario where the same prime is used  to secure a large number
  273.    of exchanges: such a prime will become an attractive
  274.    target for cryptanalysis, thus it may provide only weak security.
  275.    It also adds protection against a party that chooses weak parameters
  276.    in the DH exchange, such as weak primes or short exponents.
  277.  
  278.    Next, using encryption for authentication provides for a plausibly
  279.    deniable exchange. There is no proof (in contrast to the use of
  280.    digital signatures) that the conversation ever took place since each
  281.    party could have generated both sides of the exchange.
  282.  
  283.    Furthermore, unlike other authentication methods, authentication with
  284.    public key encryption allows for identity protection even in
  285.    Aggressive Mode.
  286.  
  287.    We remark that both the ISAKMP/Oakley Encryption Method and the
  288.    Revised Encryption method described here are based on a similar
  289.    mode in [Kra96] where a more extensive discussion on the above issues
  290.    can be found.
  291.  
  292.  
  293.  
  294.    5. Acknowledgments
  295.    ===================
  296.  
  297.    We thank Dan Harkins for helpful discussions and suggestions.
  298.  
  299.  
  300.    6. References
  301.    =============
  302.  
  303.  
  304.    [HC97] Harkins, D. and D. Carrel, "The resolution of ISAKMP with
  305.    Oakley", draft-ietf-ipsec-isakmp-oakley-03.txt, February 1997.
  306.  
  307.    [Kra96] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange
  308.    Mechanism for Internet", from IEEE Proceedings of the 1996 Symposium
  309.    on Network and Distributed Systems Security.
  310.  
  311.  
  312. Canetti, Cheng, Krawczyk                                           [Page 5]
  313.  
  314. INTERNET DRAFT                                             April 1997
  315.  
  316.    [MSST96] Maughhan, D., Schertler, M., Schneider, M., and Turner, J.,
  317.    "Internet Security Association and Key Management Protocol (ISAKMP)",
  318.    version 7, draft-ietf-ipsec-isakmp-07.{ps,txt}.
  319.  
  320.    [Pip96] Piper, D., "The Internet IP Security Domain Of Interpretation
  321.    for ISAKMP", version 2, draft-ietf-ipsec-ipsec-doi-02.txt.
  322.  
  323.  
  324.  
  325.  
  326.  
  327.    Appendix A: XCHG attribute assigned number
  328.    =========================================
  329.  
  330.    This Appendix defines a new authentication method value for the
  331.    Revised Encryption Method.  This value is to be negotiated in
  332.    Phase 1 (see [MSST96] and Appendix A in [HC97]).  The value is:
  333.  
  334.  
  335.              authentication method value
  336.              ---------------------------
  337.  
  338.               Revised RSA Encryption              5
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.    Authors'  Addresses:
  352.    ====================
  353.  
  354.  
  355. Ran Canetti                              Pau-Chen Cheng
  356. IBM TJ Watson Research Center            IBM TJ Watson Research Center
  357. POB. 704, Yorktown Heights,              POB. 704, Yorktown Heights,
  358. NY 10598                                 NY 10598
  359. Tel. 1-914-784-7076                      Tel. 1-914-784-7446
  360. canetti@watson.ibm.com                   pau@watson.ibm.com
  361.  
  362. Hugo Krawczyk
  363. IBM TJ Watson Research Center            
  364. POB. 704, Yorktown Heights,             
  365. NY 10598       
  366. hugo@ee.technion.ac.il
  367.  
  368. Canetti, Cheng, Krawczyk                                           [Page 6]
  369.  
  370.