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), ] PubKey_r, PubKey_r --> HDR, KE, PubKey_i, <-- 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]