IKEv2--1

Network Working Group                                    C. Kaufman, Ed.
Request for Comments: 4306                                     Microsoft
Obsoletes: 2407, 2408, 2409                                December 2005
Category: Standards Track

                 Internet Key Exchange (IKEv2) Protocol

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes version 2 of the Internet Key Exchange (IKE)
   protocol.  IKE is a component of IPsec used for performing mutual
   authentication and establishing and maintaining security associations
   (SAs).

   This version of the IKE specification combines the contents of what
   were previously separate documents, including Internet Security
   Association and Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC
   2409), the Internet Domain of Interpretation (DOI, RFC 2407), Network
   Address Translation (NAT) Traversal, Legacy authentication, and
   remote address acquisition.

   Version 2 of IKE does not interoperate with version 1, but it has
   enough of the header format in common that both versions can
   unambiguously run over the same UDP port.

Table of Contents

   1. Introduction ....................................................3
      1.1. Usage Scenarios ............................................5
      1.2. The Initial Exchanges ......................................7
      1.3. The CREATE_CHILD_SA Exchange ...............................9
      1.4. The INFORMATIONAL Exchange ................................11
      1.5. Informational Messages outside of an IKE_SA ...............12
   2. IKE Protocol Details and Variations ............................12
      2.1. Use of Retransmission Timers ..............................13
      2.2. Use of Sequence Numbers for Message ID ....................14
      2.3. Window Size for Overlapping Requests ......................14
      2.4. State Synchronization and Connection Timeouts .............15
      2.5. Version Numbers and Forward Compatibility .................17
      2.6. Cookies ...................................................18
      2.7. Cryptographic Algorithm Negotiation .......................21
      2.8. Rekeying ..................................................22
      2.9. Traffic Selector Negotiation ..............................24
      2.10. Nonces ...................................................26
      2.11. Address and Port Agility .................................26
      2.12. Reuse of Diffie-Hellman Exponentials .....................27
      2.13. Generating Keying Material ...............................27
      2.14. Generating Keying Material for the IKE_SA ................28
      2.15. Authentication of the IKE_SA .............................29
      2.16. Extensible Authentication Protocol Methods ...............31
      2.17. Generating Keying Material for CHILD_SAs .................33
      2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA exchange ........34
      2.19. Requesting an Internal Address on a Remote Network .......34
      2.20. Requesting the Peer's Version ............................35
      2.21. Error Handling ...........................................36
      2.22. IPComp ...................................................37
      2.23. NAT Traversal ............................................38
      2.24. Explicit Congestion Notification (ECN) ...................40
   3. Header and Payload Formats .....................................41
      3.1. The IKE Header ............................................41
      3.2. Generic Payload Header ....................................44
      3.3. Security Association Payload ..............................46
      3.4. Key Exchange Payload ......................................56
      3.5. Identification Payloads ...................................56
      3.6. Certificate Payload .......................................59
      3.7. Certificate Request Payload ...............................61
      3.8. Authentication Payload ....................................63
      3.9. Nonce Payload .............................................64
      3.10. Notify Payload ...........................................64
      3.11. Delete Payload ...........................................72
      3.12. Vendor ID Payload ........................................73
      3.13. Traffic Selector Payload .................................74
      3.14. Encrypted Payload ........................................77
      3.15. Configuration Payload ....................................79
      3.16. Extensible Authentication Protocol (EAP) Payload .........84
   4. Conformance Requirements .......................................85
   5. Security Considerations ........................................88
   6. IANA Considerations ............................................90
   7. Acknowledgements ...............................................91
   8. References .....................................................91
      8.1. Normative References ......................................91
      8.2. Informative References ....................................92
   Appendix A: Summary of Changes from IKEv1 .........................96
   Appendix B: Diffie-Hellman Groups .................................97
      B.1. Group 1 - 768 Bit MODP ....................................97
      B.2. Group 2 - 1024 Bit MODP ...................................97

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.

   Establishing this shared state in a manual fashion does not scale
   well.  Therefore, a protocol to establish this state dynamically is
   needed.  This memo describes such a protocol -- the Internet Key
   Exchange (IKE).  This is version 2 of IKE.  Version 1 of IKE was
   defined in RFCs 2407, 2408, and 2409 [Pip98, MSST98, HC98].  This
   single document is intended to replace all three of those RFCs.

   Definitions of the primitive terms in this document (such as Security
   Association or SA) can be found in [RFC4301].

   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
   "MAY" that appear in this document are to be interpreted as described
   in [Bra97].

   The term "Expert Review" is to be interpreted as defined in
   [RFC2434].

   IKE performs mutual authentication between two parties and
   establishes an IKE security association (SA) that includes shared
   secret information that can be used to efficiently establish SAs for
   Encapsulating Security Payload (ESP) [RFC4303] and/or Authentication
   Header (AH) [RFC4302] and a set of cryptographic algorithms to be
   used by the SAs to protect the traffic that they carry.  In this
   document, the term "suite" or "cryptographic suite" refers to a

   complete set of algorithms used to protect an SA.  An initiator
   proposes one or more suites by listing supported algorithms that can
   be combined into suites in a mix-and-match fashion.  IKE can also
   negotiate use of IP Compression (IPComp) [IPCOMP] in connection with
   an ESP and/or AH SA.  We call the IKE SA an "IKE_SA".  The SAs for
   ESP and/or AH that get set up through that IKE_SA we call
   "CHILD_SAs".

   All IKE communications consist of pairs of messages: a request and a
   response.  The pair is called an "exchange".  We call the first
   messages establishing an IKE_SA IKE_SA_INIT and IKE_AUTH exchanges
   and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL
   exchanges.  In the common case, there is a single IKE_SA_INIT
   exchange and a single IKE_AUTH exchange (a total of four messages) to
   establish the IKE_SA and the first CHILD_SA.  In exceptional cases,
   there may be more than one of each of these exchanges.  In all cases,
   all IKE_SA_INIT exchanges MUST complete before any other exchange
   type, then all IKE_AUTH exchanges MUST complete, and following that
   any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur
   in any order.  In some scenarios, only a single CHILD_SA is needed
   between the IPsec endpoints, and therefore there would be no
   additional exchanges.  Subsequent exchanges MAY be used to establish
   additional CHILD_SAs between the same authenticated pair of endpoints
   and to perform housekeeping functions.
   【IKEv2交换必有:IKE_SA_INIT,IKE_AUTH。此两个可以建立一个IKE_SA和一个
   CHILD_SA。如果一个IKE_SA下对应多个CHILD_SA，则可以继续使用CREATE_CHILD_SA
   来建立，每一个CHILD_SA对应一个CREATE_CHILD_SA交换。此外，还有信息交换
   INFORMATIONAL用来处理一些通知信息】

   IKE message flow always consists of a request followed by a response.
   It is the responsibility of the requester to ensure reliability.  If
   the response is not received within a timeout interval, the requester
   needs to retransmit the request (or abandon the connection).
   【当请求端没有收到响应端的回复，请求端需要重传或放弃连接，此即要求实现
   重传机制。】

   The first request/response of an IKE session (IKE_SA_INIT) negotiates
   security parameters for the IKE_SA, sends nonces, and sends Diffie-
   Hellman values.

   The second request/response (IKE_AUTH) transmits identities, proves
   knowledge of the secrets corresponding to the two identities, and
   sets up an SA for the first (and often only) AH and/or ESP CHILD_SA.

   The types of subsequent exchanges are CREATE_CHILD_SA (which creates
   a CHILD_SA) and INFORMATIONAL (which deletes an SA, reports error
   conditions, or does other housekeeping).  Every request requires a
   response.  An INFORMATIONAL request with no payloads (other than the
   empty Encrypted payload required by the syntax) is commonly used as a
   check for liveness.  These subsequent exchanges cannot be used until
   the initial exchanges have completed.

   In the description that follows, we assume that no errors occur.
   Modifications to the flow should errors occur are described in
   section 2.21.