Internet DRAFT - draft-shin-pki4ipsec-ixc

draft-shin-pki4ipsec-ixc






Pki4ipsec Working Group                                     Yongtae Shin
Internet-Draft                                              Sangchul Son
Expires: May 10, 2006                                      Kwangkyum Lee 
                                                ICN LAB of Soongsil UNIV
                                                            Jongwon Choe
                                                          Sookmyung UNIV
                                                            October 2005

    
                  Appling PKI for The Initial Exchange in IKE 
                       draft-shin-pki4ipsec-ixc-00.txt    
    

Status of this Memo 
    
   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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/lid-abstracts.txt 
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html 
   
   This Internet-Draft will expire on may 10, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.
    
Abstract 
    
   This document is describes version 1 of the Internet Key Exchange 
   Protocol. IKE is a component of IPSec used for performing mutual 
   authentication and establishing and maintaining security associations 
   (SAs). 
   Initial exchange information during IKE Processing must be protected 
   with PKI. 
 
    
Shin&Son&Lee&Choe           Expires May 10, 2006                [Page 1]

Internet-Draft  Appling PKI for The Initial Exchange in IKE October 2005 

Table of Contents 
    
   1.Introduction......................................................1 
   2.Exchanges in IKE..................................................1  
   3.Phase 1 Authenticated With Public Key Encryption..................4 
   4.About Diffie-Hellman..............................................5 
   5.The Initial Exchange with Public Key Encryption in IKE ...........5 
   Security Considerations ............................................7
   Reference ..........................................................7 
   Author's Addresses .................................................8 
    
1. Introduction 
    
   IP Security (IPSec) provides confidentiality, data integrity, access 
   control, and data source authentication to IP datagrams. 
   These services are provided by maintaining shared state between the 
   source and the sink of an IP datagram. This state defines, among 
   other things, the specific services provided to the datagram, which 
   cryptographic algorithms will be used to provide the services, and 
   the keys used as input to the cryptographic algorithms. 
    
   This document is Apply to the initial exchange in IPSec with PKI. 
        
2. Exchanges in IKE 
    
   There are two basic methods used to establish an authenticated key    
   exchange: Main Mode and Aggressive Mode. Each generates authenticated   
   keying material from an ephemeral Diffie-Hellman exchange. Main Mode   
   MUST be implemented; Aggressive Mode SHOULD be implemented. 
    
   In Addition, Quick Mode MUST be implemented as a mechanism to 
   generate fresh keying material and negotiate non-ISAKMP security 
   services. 
    
   In addition, New Group Mode SHOULD be implemented as a mechanism to 
   define private groups for Diffie-Hellman exchanges. Implementations   
   MUST NOT switch exchange types in the middle of an exchange. 
    
   Exchanges conform to standard ISAKMP payload syntax, attribute   
   encoding, timeouts and retransmits of messages, and informational 
   messages-- e.g a notify response is sent when, for example, a 
   proposal is unacceptable, or a signature verification or decryption 
   was unsuccessful, etc. 
    
   The SA payload MUST precede all other payloads in a phase 1 exchange. 
   Except where otherwise noted, there are no requirements for ISAKMP 
   payloads in any message to be in any particular order. 
   The Diffie-Hellman public value passed in a KE payload, in either a   
   phase 1 or phase 2 exchange, MUST be the length of the negotiated   
   Diffie-Hellman group enforced, if necessary, by pre-pending the value   
   with zeros. 
    
Shin&Son&Lee&Choe           Expires May 10, 2006                [Page 2]

Internet-Draft  Appling PKI for The Initial Exchange in IKE October 2005 
   
   The length of nonce payload MUST be between 8 and 256 bytes 
   inclusive. 
    
   Main Mode is an instantiation of the ISAKMP Identity Protect 
   Exchange: The first two messages negotiate policy; the next two 
   exchange Diffie-Hellman public values and ancillary data (e.g.   
   nonces) necessary for the exchange; and the last two messages   
   authenticate the Diffie-Hellman Exchange. 
 
   The authentication method negotiated as part of the initial ISAKMP 
   exchange influences the composition of the payloads but not their 
   purpose. The XCHG for Main Mode is ISAKMP Identity Protect. 
   Similarly, Aggressive Mode is an instantiation of the ISAKMP   
   Aggressive Exchange. The first two messages negotiate policy,   
   exchange Diffie-Hellman public values and ancillary data necessary   
   for the exchange, and identities.  In addition the second message   
   authenticates the responder. The third message authenticates the   
   initiator and provides a proof of participation in the exchange. 
    
   The XCHG for Aggressive Mode is ISAKMP Aggressive.  The final message 
   MAY NOT be sent under protection of the ISAKMP SA allowing each party 
   to postpone exponentiation, if desired, until negotiation of this   
   exchange is complete. The graphic depictions of Aggressive Mode show   
   the final payload in the clear; it need not be. 
    
   Exchanges in IKE are not open ended and have a fixed number of   
   messages.  Receipt of a Certificate Request payload MUST NOT extend   
   the number of messages transmitted or expected. 
    
   Security Association negotiation is limited with Aggressive Mode.  
   Due to message construction requirements the group in which the 
   Diffie-Hellman exchange is performed cannot be negotiated. 
    
   In addition, different authentication methods may further constrain 
   attribute negotiation. For example, authentication with public key 
   encryption cannot be negotiated and when using the revised method of 
   public key encryption for authentication the cipher and hash cannot 
   be negotiated. For situations where the rich attribute negotiation 
   capabilities of IKE are required Main Mode may be required. 
    
   Main Mode, Aggressive Mode, and Quick Mode do security association  
   negotiation. Security Association offers take the form of Transform   
   Payload(s) encapsulated in Proposal Payload(s) encapsulated in   
   Security Association (SA) payload(s). If multiple offers are being   
   made for phase 1 exchanges (Main Mode and Aggressive Mode) they MUST 
   take the form of multiple Transform Payloads for a single Proposal   
   Payload in a single SA payload. To put it another way, for phase 1   
   exchanges there MUST NOT be multiple Proposal Payloads for a single   
   SA payload and there MUST NOT be multiple SA payloads. This document   
   does not proscribe such behavior on offers in phase 2 exchanges. 
 
    
Shin&Son&Lee&Choe           Expires May 10, 2006                [Page 3]

Internet-Draft  Appling PKI for The Initial Exchange in IKE October 2005 


   There is no limit on the number of offers the initiator may send to 
   the responder but conformant implementations MAY choose to limit the   
   number of offers it will inspect for performance reasons. 
    
   During security association negotiation, initiators present offers 
   for potential security associations to responders. Responders MUST   
   NOT modify attributes of any offer, attribute encoding excepted.  
 
   If the initiator of an exchange notices that attribute values have 
   changed or attributes have been added or deleted from an offer made, 
   that response MUST be rejected. 
    
   Four different authentication methods are allowed with either Main   
   Mode or Aggressive Mode-- digital signature, two forms of 
   authentication with public key encryption, or pre-shared key. 
   The value SKEYID is computed seperately for each authentication 
   method. 
    
    
3. Phase 1 Authenticated With Public Key Encryption 
 
   Using public key encryption to authenticate the exchange, the   
   ancillary information exchanged is encrypted nonces. Each party's   
   ability to reconstruct a hash (proving that the other party decrypted   
   the nonce) authenticates the exchange. 
    
   In order to perform the public key encryption, the initiator must 
   already have the responder's public key. In the case where the 
   responder has multiple public keys, a hash of the certificate the    
   initiator is using to encrypt the ancillary information is passed as    
   part of the third message. In this way the responder can determine    
   which corresponding private key to use to decrypt the encrypted    
   payloads and identity protection is retained. 
    
   In addition to the nonce, the identities of the parties (IDii and    
   IDir) are also encrypted with the other party's public key. If the    
   authentication method is public key encryption, the nonce and    
   identity payloads MUST be encrypted with the public key of the other    
   party. Only the body of the payloads are encrypted, the payload 
   headers are left in the clear.  
    

   
   
   
   
   
   
   
   
   
Shin&Son&Lee&Choe           Expires May 10, 2006                [Page 4]

Internet-Draft  Appling PKI for The Initial Exchange in IKE October 2005    
    
   When using encryption for authentication, Main Mode is defined as    
   follows. 
    
           Initiator                        Responder 
          -----------                      ----------- 
           HDR, SA                   --> 
                                     <--    HDR, SA 
           HDR, KE, [ HASH(1), ] 
             <IDii_b>PubKey_r, 
               <Ni_b>PubKey_r        --> 
                                            HDR, KE, <IDir_b>PubKey_i, 
                                     <--            <Nr_b>PubKey_i 
           HDR*, HASH_I              --> 
                                     <--    HDR*, HASH_R 
       
4. About Diffie-Hellman 
    
   Diffie-Hellman requires two parties to interact to derive keying 
   information which can then be used for authentication.  Since DNS SIG 
   RRs are primarily used as stored authenticators of zone information 
   for many different resolvers, no Diffie-Hellman algorithm SIG RR is 
   defined. For example, assume that two parties have local secrets "i" 
   and "j".  Assume they each respectively calculate X and Y as follows: 
    
    
                   X = g**i ( mod p ) Y = g**j ( mod p ) 
    
      They exchange these quantities and then each calculates a Z as 
      follows: 
    
                   Zi = Y**i ( mod p ) Zj = X**j ( mod p ) 
    
   shared secret between the two parties that an adversary who does not 
   know i or j will not be able to learn from the exchanged messages 
   unless the adversary can derive i or j by performing a discrete 
   logarithm mod p which is hard for strong p and g). 
    
   The private key for each party is their secret i (or j).  The public 
   key is the pair p and g, which must be the same for the parties, and 
   their individual X (or Y). 
        
5. The Initial Exchange with Public Key Encryption in IKE 
 
   Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH    
   exchanges (known in IKEv1 as Phase 1). These initial exchanges    
   normally consist of four messages, though in some scenarios that     
   number can grow. All communications using IKE consist of 
   request/response pairs.  We'll describe the base exchange first,    
   followed by variations.  The first pair of messages (IKE_SA_INIT)    
   negotiate cryptographic algorithms, exchange nonces, and do a Diffie-    
   Hellman exchange. 
    
Shin&Son&Lee&Choe           Expires May 10, 2006                [Page 5]

Internet-Draft  Appling PKI for The Initial Exchange in IKE October 2005 

   The second pair of messages (IKE_AUTH) authenticate the previous    
   messages, exchange identities and certificates, and establish the    
   first CHILD_SA. Parts of these messages are encrypted and integrity    
   protected with keys established through the IKE_SA_INIT exchange, so    
   the identities are hidden from eavesdroppers and all fields in all    
   the messages are authenticated. 
    
   In the following description, the payloads contained in the message 
   are indicated by names such as SA. The details of the contents of 
   each payload are described later. Payloads which may optionally   
   appear will be shown in brackets, such as [CERTREQ], would indicate    
   that optionally a certificate request payload can be included. 
  
   The initial exchanges are as follows: 
    
          Initiator                          Responder 
         -----------                        ----------- 
          HDR, SAi1, KEi, Ni   --> 
    
   HDR contains the SPIs, version numbers, and flags of various sorts. 
   The SAi1 payload states the cryptographic algorithms the initiator    
   supports for the IKE_SA.  The KE payload sends the initiator's    
   Diffie-Hellman value. Ni is the initiator's nonce. 
    
                               <--    HDR, SAr1, KEr, Nr, [CERTREQ]  
    
   The responder chooses a cryptographic suite from the initiator's    
   offered choices and expresses that choice in the SAr1 payload,    
   completes the Diffie-Hellman exchange with the KEr payload, and sends    
   its nonce in the Nr payload. 
    
   At this point in the negotiation each party can generate SKEYSEED,    
   from which all keys are derived for that IKE_SA.  All but the headers    
   of all the messages that follow are encrypted and integrity    
   protected.  The keys used for the encryption and integrity protection    
   are derived from SKEYSEED and are known as SK_e (encryption) and SK_a    
   (authentication, a.k.a.  integrity protection). A separate SK_e and    
   SK_a is computed for each direction.  In addition to the keys SK_e    
   and SK_a derived from the DH value for protection of the IKE_SA,    
   another quantity SK_d is derived and used for derivation of further    
   keying material for CHILD_SAs.  The notation SK { ... } indicates    
   that these payloads are encrypted and integrity protected using that    
   direction's SK_e and SK_a. 
    
          HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 
                     AUTH, SAi2, TSi, TSr}     --> 
    
   The initiator asserts its identity with the IDi payload, proves    
   knowledge of the secret corresponding to IDi and integrity protects    
   the contents of the first message using the AUTH payload. It might 
   also send its certificate(s) in CERT payload(s) and a list of its 

Shin&Son&Lee&Choe           Expires May 10, 2006                [Page 6]

Internet-Draft  Appling PKI for The Initial Exchange in IKE October 2005    
   
   
   trust anchors in CERTREQ payload(s). If any CERT payloads are 
   included, the first certificate provided MUST contain the public key 
   used to verify the AUTH field.  The optional payload IDr enables the 
   initiator to specify which of the responder's    identities it wants 
   to talk to. This is useful when the machine on which the responder is 
   running is hosting multiple identities at the same IP address.  The 
   initiator begins negotiation of a CHILD_SA using the SAi2 payload. 
   The final fields (starting with SAi2) are described in the 
   description of the CREATE_CHILD_SA exchange. 
     
                                      <--    HDR, SK {IDr, [CERT,] AUTH, 
                                                   SAr2, TSi, TSr} 
    
   The responder asserts its identity with the IDr payload, optionally 
   sends one or more certificates (again with the certificate containing    
   the public key used to verify AUTH listed first), authenticates its    
   identity and protects the integrity of the second message with the    
   AUTH payload, and completes negotiation of a CHILD_SA with the    
   additional fields described below in the CREATE_CHILD_SA exchange. 
    
   The recipients of messages 3 and 4 MUST verify that all signatures 
   and MACs are computed correctly and that the names in the ID payloads 
   correspond to the keys used to generate the AUTH payload. 
    
    
Security Considerations 
    
   The focus of this document is security; hence security considerations 
   permeate this specification. 
    
    
Reference
                     
   1  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
      Levels", BCP 14, RFC 2119, March 1997 
    
   2  Piper, D., "The Internet IP Security Domain Of 
      Interpretation for ISAKMP", RFC 2407, November 1998. 
    
   3  D. Harkins, "The Internet Key Exchange" (RFC 2409) November 1998 
    
   4  R. Housley, "Internet X.509 Public Key Infrastructure Certificate               
      and CRL Profile" (RFC 2459)   January 1999 
    
   5  Charlie Kaufman, "Internet Key Exchange (IKEv2) Protocol" 
      September 2004 
    




Shin&Son&Lee&Choe           Expires May 10, 2006                [Page 7]

Internet-Draft  Appling PKI for The Initial Exchange in IKE October 2005 
 
Author's Addresses 
    
   Yongtae Shin 
   Room 422 Information Science B/D,  
   Soongsil University Sangdo5-dong  
   Dongjak-gu Seoul, 156-743,  
   South Korea 
   Email: shin@cherry.ssu.ac.kr 
   
   Sangchul Son 
   Room 402 Information Science B/D,  
   Soongsil University Sangdo5-dong  
   Dongjak-gu Seoul, 156-743,  
   South Korea 
   Email: yelhorse@cherry.ssu.ac.kr 
    
   Kwangkyum Lee 
   Room 402 Information Science B/D,  
   Soongsil University Sangdo5-dong  
   Dongjak-gu Seoul, 156-743,  
   South Korea 
   Email: goodwin77@cherry.ssu.ac.kr 
    
   Jongwon Choe 
   Room 410A Information Science B/D,  
   Sookmyung University Hyochangwon St.52  
   Yongsan-gu Seoul, 140-742, 
   South Korea 
   Email: choejn@sookmyung.ac.kr 
    

 

















 
 

Shin&Son&Lee&Choe           Expires May 10, 2006                [Page 8]

Internet-Draft  Appling PKI for The Initial Exchange in IKE October 2005 

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.





Shin&Son&Lee&Choe           Expires May 10, 2006                [Page 9]