返回首页

RFC 4718 - IKEv2 Clarifications and Implementation Guideline

时间:2006-11-06 来源: 作者: 点击:
NetworkWorkingGroupP.Eronen RequestforComments:4718Nokia Category:InformationalP.Hoffman VPNConsortium October2006 IKEv2ClarificationsandImplementationGuidelines StatusofThisMemo ThismemoprovidesinformationfortheInternetcommunity.Itdoes notspecifyanI
  Network Working Group                                          P. Eronen
Request for Comments: 4718                                         Nokia
Category: Informational                                       P. Hoffman
                                                          VPN Consortium
                                                            October 2006

           IKEv2 Clarifications and Implementation Guidelines

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document clarifies many areas of the IKEv2 specification.  It
   does not to introduce any changes to the protocol, but rather
   provides descriptions that are less prone to ambiguous
   interpretations.  The purpose of this document is to encourage the
   development of interoperable implementations.

Table of Contents

   1. Introduction ....................................................4
   2. Creating the IKE_SA .............................................4
      2.1. SPI Values in IKE_SA_INIT Exchange .........................4
      2.2. Message IDs for IKE_SA_INIT Messages .......................5
      2.3. Retransmissions of IKE_SA_INIT Requests ....................5
      2.4. Interaction of COOKIE and INVALID_KE_PAYLOAD ...............6
      2.5. Invalid Cookies ............................................8
   3. Authentication ..................................................9
      3.1. Data Included in AUTH Payload Calculation ..................9
      3.2. Hash Function for RSA Signatures ...........................9
      3.3. Encoding Method for RSA Signatures ........................10
      3.4. Identification Type for EAP ...............................11
      3.5. Identity for Policy Lookups When Using EAP ................11
      3.6. Certificate Encoding Types ................................12
      3.7. Shared Key Authentication and Fixed PRF Key Size ..........12
      3.8. EAP Authentication and Fixed PRF Key Size .................13
      3.9. Matching ID Payloads to Certificate Contents ..............13
      3.10. Message IDs for IKE_AUTH Messages ........................14
   4. Creating CHILD_SAs .............................................14
      4.1. Creating SAs with the CREATE_CHILD_SA Exchange ............14
      4.2. Creating an IKE_SA without a CHILD_SA .....................16
      4.3. Diffie-Hellman for First CHILD_SA .........................16
      4.4. Extended Sequence Numbers (ESN) Transform .................17
      4.5. Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED ..............17
      4.6. Negotiation of NON_FIRST_FRAGMENTS_ALSO ...................18
      4.7. Semantics of Complex Traffic Selector Payloads ............18
      4.8. ICMP Type/Code in Traffic Selector Payloads ...............19
      4.9. Mobility Header in Traffic Selector Payloads ..............20
      4.10. Narrowing the Traffic Selectors ..........................20
      4.11. SINGLE_PAIR_REQUIRED .....................................21
      4.12. Traffic Selectors Violating Own Policy ...................21
      4.13. Traffic Selector Authorization ...........................22
   5. Rekeying and Deleting SAs ......................................23
      5.1. Rekeying SAs with the CREATE_CHILD_SA Exchange ............23
      5.2. Rekeying the IKE_SA vs. Reauthentication ..................24
      5.3. SPIs When Rekeying the IKE_SA .............................25
      5.4. SPI When Rekeying a CHILD_SA ..............................25
      5.5. Changing PRFs When Rekeying the IKE_SA ....................26
      5.6. Deleting vs. Closing SAs ..................................26
      5.7. Deleting a CHILD_SA Pair ..................................26
      5.8. Deleting an IKE_SA ........................................27
      5.9. Who is the original initiator of IKE_SA ...................27
      5.10. Comparing Nonces .........................................27
      5.11. Exchange Collisions ......................................28
      5.12. Diffie-Hellman and Rekeying the IKE_SA ...................36

   6. Configuration Payloads .........................................37
      6.1. Assigning IP Addresses ....................................37
      6.2. Requesting any INTERNAL_IP4/IP6_ADDRESS ...................38
      6.3. INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET ...................38
      6.4. INTERNAL_IP4_NETMASK ......................................41
      6.5. Configuration Payloads for IPv6 ...........................42
      6.6. INTERNAL_IP6_NBNS .........................................43
      6.7. INTERNAL_ADDRESS_EXPIRY ...................................43
      6.8. Address Assignment Failures ...............................44
   7. Miscellaneous Issues ...........................................45
      7.1. Matching ID_IPV4_ADDR and ID_IPV6_ADDR ....................45
      7.2. Relationship of IKEv2 to RFC 4301 .........................45
      7.3. Reducing the Window Size ..................................46
      7.4. Minimum Size of Nonces ....................................46
      7.5. Initial Zero Octets on Port 4500 ..........................46
      7.6. Destination Port for NAT Traversal ........................47
      7.7. SPI Values for Messages outside an IKE_SA .................47
      7.8. Protocol ID/SPI Fields in Notify Payloads .................48
      7.9. Which message should contain INITIAL_CONTACT ..............48
      7.10. Alignment of Payloads ....................................48
      7.11. Key Length Transform Attribute ...........................48
      7.12. IPsec IANA Considerations ................................49
      7.13. Combining ESP and AH .....................................50
   8. Implementation Mistakes ........................................50
   9. Security Considerations ........................................51
   10. Acknowledgments ...............................................51
   11. References ....................................................51
      11.1. Normative References .....................................51
      11.2. Informative References ...................................52
   Appendix A. Exchanges and Payloads ................................54
      A.1. IKE_SA_INIT Exchange ......................................54
      A.2. IKE_AUTH Exchange without EAP .............................54
      A.3. IKE_AUTH Exchange with EAP ................................55
      A.4. CREATE_CHILD_SA Exchange for Creating/Rekeying
           CHILD_SAs .................................................56
      A.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA ..........56
      A.6. INFORMATIONAL Exchange ....................................56

1.  Introduction

   This document clarifies many areas of the IKEv2 specification that
   may be difficult to understand to developers not intimately familiar
   with the specification and its history.  The clarifications in this
   document come from the discussion on the IPsec WG mailing list, from
   experience in interoperability testing, and from implementation
   issues that have been brought to the editors’ attention.

   IKEv2/IPsec can be used for several different purposes, including
   IPsec-based remote access (sometimes called the "road warrior" case),
   site-to-site virtual private networks (VPNs), and host-to-host
   protection of application traffic.  While this document attempts to
   consider all of these uses, the remote access scenario has perhaps
   received more attention here than the other uses.

   This document does not place any requirements on anyone and does not
   use [RFC2119] keywords such as "MUST" and "SHOULD", except in
   quotations from the original IKEv2 documents.  The requirements are
   given in the IKEv2 specification [IKEv2] and IKEv2 cryptographic
   algorithms document [IKEv2ALG].

   In this document, references to a numbered section (such as "Section
   2.15") mean that section in [IKEv2].  References to mailing list
   messages or threads refer to the IPsec WG mailing list at
   ipsec@ietf.org.  Archives of the mailing list can be found at
   <http://www.ietf.org/mail-archive/web/ipsec/index.html>.

2.  Creating the IKE_SA

2.1.  SPI Values in IKE_SA_INIT Exchange

   Normal IKE messages include the initiator’s and responder’s Security
   Parameter Indexes (SPIs), both of which are non-zero, in the IKE
   header.  However, there are some corner cases where the IKEv2
   specification is not fully consistent about what values should be
   used.

   First, Section 3.1 says that the Responder’s SPI "...MUST NOT be zero
   in any other message" (than the first message of the IKE_SA_INIT
   exchange).  However, the figure in Section 2.6 shows the second
   IKE_SA_INIT message as "HDR(A,0), N(COOKIE)", contradicting the text
   in 3.1.

   Since the responder’s SPI identifies security-related state held by
   the responder, and in this case no state is created, sending a zero
   value seems reasonable.

   Second, in addition to cookies, there are several other cases when
   the IKE_SA_INIT exchange does not result in the creation of an IKE_SA
   (for instance, INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN).  What
   responder SPI value should be used in the IKE_SA_INIT response in
   this case?

   Since the IKE_SA_INIT request always has a zero responder SPI, the
   value will not be actually used by the initiator.  Thus, we think
   sending a zero value is correct also in this case.

   If the responder sends a non-zero responder SPI, the initiator should
   not reject the response only for that reason.  However, when retrying
   the IKE_SA_INIT request, the initiator will use a zero responder SPI,
   as described in Section 3.1: "Responder’s SPI [...]  This value MUST
   be zero in the first message of an IKE Initial Exchange (including
   repeats of that message including a cookie) [...]".  We believe the
   intent was to cover repeats of that message due to other reasons,
   such as INVALID_KE_PAYLOAD, as well.

   (References: "INVALID_KE_PAYLOAD and clarifications document" thread,
   Sep-Oct 2005.)

2.2.  Message IDs for IKE_SA_INIT Messages

   The Message ID for IKE_SA_INIT messages is always zero.  This
   includes retries of the message due to responses such as COOKIE and
   INVALID_KE_PAYLOAD.

   This is because Message IDs are part of the IKE_SA state, and when
   the responder replies to IKE_SA_INIT request with N(COOKIE) or
   N(INVALID_KE_PAYLOAD), the responder does not allocate any state.

   (References: "Question about N(COOKIE) and N(INVALID_KE_PAYLOAD)
   combination" thread, Oct 2004.  Tero Kivinen’s mail "Comments of
   draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.)

2.3.  Retransmissions of IKE_SA_INIT Requests

   When a responder receives an IKE_SA_INIT request, it has to determine
   whether the packet is a retransmission belonging to an existing
   "half-open" IKE_SA (in which case the responder retransmits the same
   response), or a new request (in which case the responder creates a
   new IKE_SA and sends a fresh response).

   The specification does not describe in detail how this determination
   is done.  In particular, it is not sufficient to use the initiator’s
   SPI and/or IP address for this purpose: two different peers behind a
   single NAT could choose the same initiator SPI (and the probability

   of this happening is not necessarily small, since IKEv2 does not
   require SPIs to be chosen randomly).  Instead, the responder should
   do the IKE_SA lookup using the whole packet or its hash (or at the
   minimum, the Ni payload which is always chosen randomly).

   For all other packets than IKE_SA_INIT requests, looking up right
   IKE_SA is of course done based on the recipient’s SPI (either the
   initiator or responder SPI depending on the value of the Initiator
   bit in the IKE header).

2.4.  Interaction of COOKIE and INVALID_KE_PAYLOAD

   There are two common reasons why the initiator may have to retry the
   IKE_SA_INIT exchange: the responder requests a cookie or wants a
   different Diffie-Hellman group than was included in the KEi payload.
   Both of these cases are quite simple alone, but it is not totally
   obvious what happens when they occur at the same time, that is, the
   IKE_SA_INIT exchange is retried several times.

   The main question seems to be the following: if the initiator
   receives a cookie from the responder, should it include the cookie in
   only the next retry of the IKE_SA_INIT request, or in all subsequent
   retries as well?  Section 3.10.1 says that:

      "This notification MUST be included in an IKE_SA_INIT request
      retry if a COOKIE notification was included in the initial
      response."

   This could be interpreted as saying that when a cookie is received in
   the initial response, it is included in all retries.  On the other
   hand, Section 2.6 says that:

      "Initiators who receive such responses MUST retry the
      IKE_SA_INIT with a Notify payload of type COOKIE containing
      the responder supplied cookie data as the first payload and
      all other payloads unchanged."

   Including the same cookie in later retries makes sense only if the
   "all other payloads unchanged" restriction applies only to the first
   retry, but not to subsequent retries.

   It seems that both interpretations can peacefully coexist.  If the
   initiator includes the cookie only in the next retry, one additional
   roundtrip may be needed in some cases:

      Initiator                   Responder
     -----------                 -----------
      HDR(A,0), SAi1, KEi, Ni -->
                              <-- HDR(A,0), N(COOKIE)
      HDR(A,0), N(COOKIE), SAi1, KEi, Ni  -->
                              <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
      HDR(A,0), SAi1, KEi’, Ni -->
                              <-- HDR(A,0), N(COOKIE’)
      HDR(A,0), N(COOKIE’), SAi1, KEi’,Ni -->
                              <-- HDR(A,B), SAr1, KEr, Nr

   An additional roundtrip is needed also if the initiator includes the
   cookie in all retries, but the responder does not support this
   functionality.  For instance, if the responder includes the SAi1 and
   KEi payloads in cookie calculation, it will reject the request by
   sending a new cookie (see also Section 2.5 of this document for more
   text about invalid cookies):

      Initiator                   Responder
     -----------                 -----------
      HDR(A,0), SAi1, KEi, Ni -->
                              <-- HDR(A,0), N(COOKIE)
      HDR(A,0), N(COOKIE), SAi1, KEi, Ni  -->
                              <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
      HDR(A,0), N(COOKIE), SAi1, KEi’, Ni -->
                              <-- HDR(A,0), N(COOKIE’)
      HDR(A,0), N(COOKIE’), SAi1, KEi’,Ni -->
                              <-- HDR(A,B), SAr1, KEr, Nr

   If both peers support including the cookie in all retries, a slightly
   shorter exchange can happen:

      Initiator                   Responder
     -----------                 -----------
      HDR(A,0), SAi1, KEi, Ni -->
                              <-- HDR(A,0), N(COOKIE)
      HDR(A,0), N(COOKIE), SAi1, KEi, Ni  -->
                              <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
      HDR(A,0), N(COOKIE), SAi1, KEi’, Ni -->
                              <-- HDR(A,B), SAr1, KEr, Nr

   This document recommends that implementations should support this
   shorter exchange, but it must not be assumed the other peer also
   supports the shorter exchange.

   In theory, even this exchange has one unnecessary roundtrip, as both
   the cookie and Diffie-Hellman group could be checked at the same
   time:

      Initiator                   Responder
     -----------                 -----------
      HDR(A,0), SAi1, KEi, Ni -->
                              <-- HDR(A,0), N(COOKIE),
                                            N(INVALID_KE_PAYLOAD)
      HDR(A,0), N(COOKIE), SAi1, KEi’,Ni -->
                              <-- HDR(A,B), SAr1, KEr, Nr

   However, it is clear that this case is not allowed by the text in
   Section 2.6, since "all other payloads" clearly includes the KEi
   payload as well.

   (References: "INVALID_KE_PAYLOAD and clarifications document" thread,
   Sep-Oct 2005.)

2.5.  Invalid Cookies

   There has been some confusion what should be done when an IKE_SA_INIT
   request containing an invalid cookie is received ("invalid" in the
   sense that its contents do not match the value expected by the
   responder).

   The correct action is to ignore the cookie and process the message as
   if no cookie had been included (usually this means sending a response
   containing a new cookie).  This is shown in Section 2.6 when it says
   "The responder in that case MAY reject the message by sending another
   response with a new cookie [...]".

   Other possible actions, such as ignoring the whole request (or even
   all requests from this IP address for some time), create strange
   failure modes even in the absence of any malicious attackers and do
   not provide any additional protection against DoS attacks.

   (References: "Invalid Cookie" thread, Sep-Oct 2005.)

3.  Authentication

3.1.  Data Included in AUTH Payload Calculation

   Section 2.15 describes how the AUTH payloads are calculated; this
   calculation involves values prf(SK_pi,IDi’) and prf(SK_pr,IDr’).  The
   text describes the method in words, but does not give clear
   definitions of what is signed or MACed (i.e., protected with a
   message authentication code).

   The initiator’s signed octets can be described as:

       InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
       GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
       RealIKEHDR =  SPIi | SPIr |  . . . | Length
       RealMessage1 = RealIKEHDR | RestOfMessage1
       NonceRPayload = PayloadHeader | NonceRData
       InitiatorIDPayload = PayloadHeader | RestOfIDPayload
       RestOfInitIDPayload = IDType | RESERVED | InitIDData
       MACedIDForI = prf(SK_pi, RestOfInitIDPayload)

   The responder’s signed octets can be described as:

       ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
       GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
       RealIKEHDR =  SPIi | SPIr |  . . . | Length
       RealMessage2 = RealIKEHDR | RestOfMessage2
       NonceIPayload = PayloadHeader | NonceIData
       ResponderIDPayload = PayloadHeader | RestOfIDPayload
       RestOfRespIDPayload = IDType | RESERVED | InitIDData
       MACedIDForR = prf(SK_pr, RestOfRespIDPayload)

3.2.  Hash Function for RSA Signatures

   Section 3.8 says that RSA digital signature is "Computed as specified
   in section 2.15 using an RSA private key over a PKCS#1 padded hash."

   Unlike IKEv1, IKEv2 does not negotiate a hash function for the
   IKE_SA.  The algorithm for signatures is selected by the signing
   party who, in general, may not know beforehand what algorithms the
   verifying party supports.  Furthermore, [IKEv2ALG] does not say what
   algorithms implementations are required or recommended to support.
   This clearly has a potential for causing interoperability problems,
   since authentication will fail if the signing party selects an
   algorithm that is not supported by the verifying party, or not
   acceptable according to the verifying party’s policy.

   This document recommends that all implementations support SHA-1 and
   use SHA-1 as the default hash function when generating the
   signatures, unless there are good reasons (such as explicit manual
   configuration) to believe that the peer supports something else.

   Note that hash function collision attacks are not important for the
   AUTH payloads, since they are not intended for third-party
   verification, and the data includes fresh nonces.  See [HashUse] for
   more discussion about hash function attacks and IPsec.

   Another reasonable choice would be to use the hash function that was
   used by the CA when signing the peer certificate.  However, this does
   not guarantee that the IKEv2 peer would be able to validate the AUTH
   payload, because the same code might not be used to validate
   certificate signatures and IKEv2 message signatures, and these two
   routines may support a different set of hash algorithms.  The peer
   could be configured with a fingerprint of the certificate, or
   certificate validation could be performed by an external entity using
   [SCVP].  Furthermore, not all CERT payloads types include a
   signature, and the certificate could be signed with some algorithm
   other than RSA.

   Note that unlike IKEv1, IKEv2 uses the PKCS#1 v1.5 [PKCS1v20]
   signature encoding method (see next section for details), which
   includes the algorithm identifier for the hash algorithm.  Thus, when
   the verifying party receives the AUTH payload it can at least
   determine which hash function was used.

   (References: Magnus Alstrom’s mail "RE:", 2005-01-03.  Pasi Eronen’s
   reply, 2005-01-04.  Tero Kivinen’s reply, 2005-01-04.  "First draft
   of IKEv2.1" thread, Dec 2005/Jan 2006.)

3.3.  Encoding Method for RSA Signatures

   Section 3.8 says that the RSA digital signature is "Computed as
   specified in section 2.15 using an RSA private key over a PKCS#1
   padded hash."

   The PKCS#1 specification [PKCS1v21] defines two different encoding
   methods (ways of "padding the hash") for signatures.  However, the
   Internet-Draft approved by the IESG had a reference to the older
   PKCS#1 v2.0 [PKCS1v20].  That version has only one encoding method
   for signatures (EMSA-PKCS1-v1_5), and thus there is no ambiguity.

   Note that this encoding method is different from the encoding method
   used in IKEv1.  If future revisions of IKEv2 provide support for
   other encoding methods (such as EMSA-PSS), they will be given new
   Auth Method numbers.

   (References: Pasi Eronen’s mail "RE:", 2005-01-04.)

3.4.  Identification Type for EAP

   Section 3.5 defines several different types for identification
   payloads, including, e.g., ID_FQDN, ID_RFC822_ADDR, and ID_KEY_ID.
   EAP [EAP] does not mandate the use of any particular type of
   identifier, but often EAP is used with Network Access Identifiers
   (NAIs) defined in [NAI].  Although NAIs look a bit like email
   addresses (e.g., "joe@example.com"), the syntax is not exactly the
   same as the syntax of email address in [RFC822].  This raises the
   question of which identification type should be used.

   This document recommends that ID_RFC822_ADDR identification type is
   used for those NAIs that include the realm component.  Therefore,
   responder implementations should not attempt to verify that the
   contents actually conform to the exact syntax given in [RFC822] or
   [RFC2822], but instead should accept any reasonable looking NAI.

   For NAIs that do not include the realm component, this document
   recommends using the ID_KEY_ID identification type.

   (References: "need your help on this IKEv2/i18n/EAP issue" and "IKEv2
   identifier issue with EAP" threads, Aug 2004.)

3.5.  Identity for Policy Lookups When Using EAP

   When the initiator authentication uses EAP, it is possible that the
   contents of the IDi payload is used only for AAA routing purposes and
   selecting which EAP method to use.  This value may be different from
   the identity authenticated by the EAP method (see [EAP], Sections 5.1
   and 7.3).

   It is important that policy lookups and access control decisions use
   the actual authenticated identity.  Often the EAP server is
   implemented in a separate AAA server that communicates with the IKEv2
   responder using, e.g., RADIUS [RADEAP].  In this case, the
   authenticated identity has to be sent from the AAA server to the
   IKEv2 responder.

   (References: Pasi Eronen’s mail "RE: Reauthentication in IKEv2",
   2004-10-28.  "Policy lookups" thread, Oct/Nov 2004.  RFC 3748,
   Section 7.3.)

3.6.  Certificate Encoding Types

   Section 3.6 defines a total of twelve different certificate encoding
   types, and continues that "Specific syntax is for some of the
   certificate type codes above is not defined in this document."
   However, the text does not provide references to other documents that
------分隔线----------------------------
顶一下
(1)
50%
踩一下
(1)
50%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容