idnits 2.17.1 draft-eronen-ipsec-ikev2-clarifications-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1581. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 15 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 27, 2005) is 6970 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'KEi' is mentioned on line 512, but not defined == Missing Reference: 'KEr' is mentioned on line 525, but not defined -- Looks like a reference, but probably isn't: '1' on line 683 == Unused Reference: 'EAPKey' is defined on line 1479, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2437 (ref. 'PKCS1v20') (Obsoleted by RFC 3447) ** Obsolete normative reference: RFC 3447 (ref. 'PKCS1v21') (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-rfc2401bis-05 == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-04 -- Obsolete informational reference (is this intentional?): RFC 3513 (ref. 'IPv6Addr') (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. 'MIPv6') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 2486 (ref. 'NAI') (Obsoleted by RFC 4282) == Outdated reference: A later version (-06) exists of draft-ietf-radext-rfc2486bis-03 -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) == Outdated reference: A later version (-05) exists of draft-nir-ikev2-auth-lt-01 == Outdated reference: A later version (-33) exists of draft-ietf-pkix-scvp-16 Summary: 8 errors (**), 0 flaws (~~), 13 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Eronen 3 Internet-Draft Nokia 4 Expires: September 25, 2005 P. Hoffman 5 VPN Consortium 6 March 27, 2005 8 IKEv2 Clarifications and Implementation Guidelines 9 draft-eronen-ipsec-ikev2-clarifications-02.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 25, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document clarifies many areas of the IKEv2 specification. It 45 does not to introduce any changes to the protocol, but rather 46 provides descriptions that are less prone to ambiguous 47 interpretations. The purpose of this document is to encourage the 48 development of interoperable implementations. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Authentication . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1 Data included in AUTH payload calculation . . . . . . . . 4 55 2.2 Hash function for RSA signatures . . . . . . . . . . . . . 5 56 2.3 Encoding method for RSA signatures . . . . . . . . . . . . 6 57 2.4 Identification type for EAP . . . . . . . . . . . . . . . 6 58 2.5 Identity for policy lookups when using EAP . . . . . . . . 7 59 2.6 EAP authentication and the AUTH payload . . . . . . . . . 7 60 2.7 Certificate encoding types . . . . . . . . . . . . . . . . 7 61 2.8 Shared key authentication and fixed PRF key size . . . . . 8 62 2.9 EAP authentication and fixed PRF key size . . . . . . . . 9 63 3. Keying and rekeying . . . . . . . . . . . . . . . . . . . . 9 64 3.1 Semantics of the CREATE_CHILD_SA exchange . . . . . . . . 9 65 3.2 Rekeying the IKE_SA vs. reauthentication . . . . . . . . . 13 66 3.3 SPIs when rekeying the IKE_SA . . . . . . . . . . . . . . 13 67 3.4 SPI when rekeying a CHILD_SA . . . . . . . . . . . . . . . 14 68 3.5 Deleting SAs . . . . . . . . . . . . . . . . . . . . . . . 14 69 4. Traffic selectors . . . . . . . . . . . . . . . . . . . . . 14 70 4.1 Semantics of complex traffic selector payloads . . . . . . 14 71 4.2 ICMP type/code in traffic selector payloads . . . . . . . 15 72 4.3 Mobility header in traffic selector payloads . . . . . . . 15 73 4.4 Narrowing the traffic selectors . . . . . . . . . . . . . 15 74 4.5 SINGLE_PAIR_REQUIRED . . . . . . . . . . . . . . . . . . . 16 75 4.6 Traffic selectors violating own policy . . . . . . . . . . 16 76 5. Configuration payloads . . . . . . . . . . . . . . . . . . . 17 77 5.1 Length of configuration attribute type field . . . . . . . 17 78 5.2 Requesting any INTERNAL_IP4/IP6_ADDRESS . . . . . . . . . 17 79 5.3 INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . . . . . . . . . 18 80 5.4 INTERNAL_IP4_NETMASK . . . . . . . . . . . . . . . . . . . 20 81 5.5 Configuration payloads for IPv6 . . . . . . . . . . . . . 22 82 5.6 INTERNAL_IP6_ADDRESS prefix length . . . . . . . . . . . . 22 83 5.7 INTERNAL_IP6_NBNS . . . . . . . . . . . . . . . . . . . . 23 84 6. Miscellaneous issues . . . . . . . . . . . . . . . . . . . . 23 85 6.1 Diffie-Hellman for first CHILD_SA . . . . . . . . . . . . 24 86 6.2 Extended Sequence Numbers (ESN) transform . . . . . . . . 24 87 6.3 Matching ID_IPV4_ADDR and ID_IPV6_ADDR . . . . . . . . . . 24 88 6.4 Relationship of IKEv2 to RFC2401bis . . . . . . . . . . . 25 89 6.5 Reducing the window size . . . . . . . . . . . . . . . . . 25 90 6.6 Minimum size of nonces . . . . . . . . . . . . . . . . . . 25 91 6.7 Initial zero octets on port 4500 . . . . . . . . . . . . . 25 92 6.8 SPI values in IKE_SA_INIT exchange . . . . . . . . . . . . 26 93 6.9 SPI values for messages outside of an IKE_SA . . . . . . . 27 94 6.10 Protocol ID/SPI fields in Notify payloads . . . . . . . 27 95 6.11 INVALID_IKE_SPI . . . . . . . . . . . . . . . . . . . . 27 96 6.12 Which message should contain INITIAL_CONTACT . . . . . . 28 97 7. Status of the clarifications . . . . . . . . . . . . . . . . 28 98 8. Implementation mistakes . . . . . . . . . . . . . . . . . . 30 99 9. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 30 100 10. Security considerations . . . . . . . . . . . . . . . . . . 31 101 11. IANA considerations . . . . . . . . . . . . . . . . . . . . 31 102 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 31 103 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 104 13.1 Normative References . . . . . . . . . . . . . . . . . . . 32 105 13.2 Informative References . . . . . . . . . . . . . . . . . . 32 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34 107 Intellectual Property and Copyright Statements . . . . . . . 35 109 1. Introduction 111 This document clarifies many areas of the IKEv2 specification that 112 may be difficult to understand to developers not intimately familiar 113 with the specification and its history. The clarifications in this 114 document come from the discussion on the IPsec WG mailing list, from 115 experience in interoperability testing, and from implementation 116 issues that have been brought to the editors' attention. 118 Readers are advised that this document is work-in-progress, and may 119 contain incorrect interpretations. Issues where the clarification is 120 known to be incomplete, or there is no consensus on what the the 121 interpretation should be, are marked as such. 123 IKEv2/IPsec can be used for several different purposes, including 124 IPsec-based remote access (sometimes called the "road warrior" case), 125 site-to-site virtual private networks (VPNs), and host-to-host 126 protection of application traffic. While this document attempts to 127 consider all of these uses, the remote access scenario has perhaps 128 received more attention here than the other uses. 130 This document does not place any requirements on anyone, and does not 131 use [RFC2119] keywords such as "MUST" and "SHOULD", except in 132 quotations from the original IKEv2 documents. The requirements are 133 given in the IKEv2 specification [IKEv2] and IKEv2 cryptographic 134 algorithms document [IKEv2ALG]. 136 In this document, references to a numbered section (such as "Section 137 2.15") mean that section in [IKEv2]. References to mailing list 138 messages refer to the IPsec WG mailing list at ipsec@ietf.org. 139 Archives of the mailing list can be found at 140 . 142 2. Authentication 144 2.1 Data included in AUTH payload calculation 146 Section 2.15 describes how the AUTH payloads are calculated; this 147 calculation involves values prf(SK_pi,IDi') and prf(SK_pr,IDr'). The 148 text describes the method in words, but does not give clear 149 definitions of what is signed or MACed. 151 The initiator's signed octets can be described as: 153 InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI 154 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 155 RealIKEHDR = SPIi | SPIr | . . . | Length 156 RealMessage1 = RealIKEHDR | RestOfMessage1 157 NonceRPayload = PayloadHeader | NonceRData 158 InitiatorIDPayload = PayloadHeader | RestOfIDPayload 159 RestOfInitIDPayload = IDType | RESERVED | InitIDData 160 MACedIDForI = prf(SK_pi, RestOfInitIDPayload) 162 The responder's signed octets can be described as: 164 ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR 165 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 166 RealIKEHDR = SPIi | SPIr | . . . | Length 167 RealMessage2 = RealIKEHDR | RestOfMessage2 168 NonceIPayload = PayloadHeader | NonceIData 169 ResponderIDPayload = PayloadHeader | RestOfIDPayload 170 RestOfRespIDPayload = IDType | RESERVED | InitIDData 171 MACedIDForR = prf(SK_pr, RestOfRespIDPayload) 173 2.2 Hash function for RSA signatures 175 Section 3.8 says that RSA digital signature is "Computed as specified 176 in section 2.15 using an RSA private key over a PKCS#1 padded hash." 178 Unlike IKEv1, IKEv2 does not negotiate a hash function for the 179 IKE_SA. The algorithm for signatures is selected by the signing 180 party who, in general, may not know beforehand what algorithms the 181 verifying party supports. Furthermore, [IKEv2ALG] does not say what 182 algorithms implementations are required or recommended to support. 183 This clearly has a potential for causing interoperability problems, 184 since authentication will fail if the signing party selects an 185 algorithm that is not supported by the verifying party, or not 186 acceptable according to the verifying party's policy. 188 This document recommends that all implementations support SHA-1, and 189 use SHA-1 as the default hash function when generating the 190 signatures, unless there are good reasons (such as explicit manual 191 configuration) to believe that the other end supports something else. 193 Note that unlike IKEv1, IKEv2 uses the PKCS#1 v1.5 [PKCS1v20] 194 signature encoding method (see next section for details), which 195 includes the algorithm identifier for the hash algorithm. Thus, when 196 the verifying party receives the AUTH payload it can determine which 197 hash function was used. 199 Other possible choices include, for example, using the hash function 200 that was used to sign the certificate. However, this approach 201 assumes that the recipient's "IKEv2 module" supports the same 202 algorithms as the "certificate validation module" (which may not be 203 true, especially if something like [SCVP] is used). Furthermore, not 204 all CERT payloads types include a signature; and the certificate 205 could be signed with some other algorithm than RSA. 207 (References: Magnus Alstrom's mail "RE:", 2005-01-03. Pasi Eronen's 208 reply, 2005-01-04. Tero Kivinen's reply, 2005-01-04.) 210 2.3 Encoding method for RSA signatures 212 Section 3.8 says that the RSA digital signature is "Computed as 213 specified in section 2.15 using an RSA private key over a PKCS#1 214 padded hash." 216 The current version of PKCS#1 (v2.1) [PKCS1v21] defines two different 217 encoding methods (ways of "padding the hash") for signatures. 218 However, IKEv2 points to the older PKCS#1 v2.0 [PKCS1v20]. That 219 version has only one encoding method for signatures 220 (EMSA-PKCS1-v1_5), and thus there is no ambiguity. 222 Note that this encoding method is different from the encoding method 223 used in IKEv1. If future revisions of IKEv2 provide support for 224 other encoding methods (such as EMSA-PSS), they will be given new 225 Auth Method numbers. 227 (References: Pasi Eronen's mail "RE:", 2005-01-04.) 229 2.4 Identification type for EAP 231 Section 3.5 defines several different types for identification 232 payloads, including, e.g., ID_FQDN, ID_RFC822_ADDR, and ID_KEY_ID. 233 EAP [EAP] does not mandate the use of any particular type of 234 identifier, but often EAP is used with Network Access Identifiers 235 (NAIs) defined in [NAI] and [NAIbis]. Although NAIs look a bit like 236 email addresses (e.g., "joe@example.com"), the syntax is not exactly 237 the same as the syntax of email address in [RFC822]. This raises the 238 question of which identification type should be used. 240 This document recommends that ID_RFC822_ADDR identification type is 241 used for those NAIs that include the realm component. Therefore, 242 responder implementations should not attempt to verify that the 243 contents actually conform to the exact syntax given in [RFC822] or 244 [RFC2822], but instead should accept any reasonable looking NAI. 246 For NAIs that do not include the realm component, this document 247 recommends using the ID_KEY_ID identification type. 249 (References: "need your help on this IKEv2/i18n/EAP issue" and "IKEv2 250 identifier issue with EAP" threads, Aug 2004.) 252 2.5 Identity for policy lookups when using EAP 254 When the initiator authentication uses EAP, it is possible that the 255 contents of the IDi payload is used only for AAA routing purposes and 256 selecting which EAP method to use. This value may be different from 257 the identity authenticated by the EAP method (see [EAP], Sections 5.1 258 and 7.3). 260 It is important that policy lookups and access control decisions use 261 the actual authenticated identity. Often the EAP server is 262 implemented in a separate AAA server that communicates with the IKEv2 263 responder using, e.g., RADIUS [RADEAP]. In this case, the 264 authenticated identity has to be sent from the AAA server to the 265 IKEv2 responder. 267 (References: Pasi Eronen's mail "RE: Reauthentication in IKEv2", 268 2004-10-28. "Policy lookups" thread, Oct/Nov 2004. RFC 3748, 269 Section 7.3.) 271 2.6 EAP authentication and the AUTH payload 273 Section 2.16 says that "For EAP methods that create a shared key as a 274 side effect of authentication, that shared key MUST be used by both 275 the initiator and responder to generate AUTH payloads in messages 5 276 and 6 using the syntax for shared secrets specified in section 2.15." 278 This text should say "messages 7 and 8". 280 (References: "How to do authentication with EAP" thread, Feb 2005) 282 2.7 Certificate encoding types 284 Section 3.6 defines a total of twelve different certificate encoding 285 types, and continues that "Specific syntax is for some of the 286 certificate type codes above is not defined in this document." 287 However, the text does not provide references to other documents that 288 would contain information about the exact contents and use of those 289 values. 291 Without this information, it is not possible to develop interoperable 292 implementations. Therefore, this document recommends that the 293 following certificate encoding values should not be used before new 294 specifications that specify their use are available. 296 PKCS #7 wrapped X.509 certificate 1 297 PGP Certificate 2 298 DNS Signed Key 3 299 Kerberos Token 6 300 SPKI Certificate 9 302 (Future versions of this document may also contain clarifications 303 about how these values are to be used.) 305 This document recommends that most implementations should use only 306 those values that are "MUST"/"SHOULD" requirements in [IKEv2]; i.e., 307 "X.509 Certificate - Signature" (4), "Raw RSA Key" (11), "Hash and 308 URL of X.509 certificate" (12), and "Hash and URL of X.509 bundle" 309 (13). 311 Furthermore, Section 3.7 says that the "Certificate Encoding" field 312 for the Certificate Request payload uses the same values as for 313 Certificate payload. However, the contents of the "Certification 314 Authority" field are defined only for X.509 certificates (presumably 315 covering at least types 4, 10, 12, and 13). This document recommends 316 that other values should not be used before new specifications that 317 specify their use are available. 319 2.8 Shared key authentication and fixed PRF key size 321 Section 2.15 says that "If the negotiated prf takes a fixed size key, 322 the shared secret MUST be of that fixed size". This statement is 323 correct: the shared secret must be of the correct size. If it is 324 not, it cannot be used; there is no padding, truncation, or other 325 processing involved to force it to that correct size. 327 This requirement means that it is difficult to use these PRFs with 328 shared key authentication. The authors think this part of the 329 specification was very poorly thought out, and using PRFs with a 330 fixed key size is likely to result in interoperability problems. 331 Thus, we recommend that such PRFs (currently only PRF_AES128_CBC) 332 should not be used with shared key authentication. 334 Note that Section 2.13 also contains text that is related to PRFs 335 with fixed key size: "When the key for the prf function has fixed 336 length, the data provided as a key is truncated or padded with zeros 337 as necessary unless exceptional processing is explained following the 338 formula". However, this text applies only to the prf+ construction, 339 so it does not contradict the text in Section 2.15. 341 (References: Paul Hoffman's mail "Re: ikev2-07: last nits", 342 2003-05-02. Hugo Krawczyk's reply, 2003-05-12. Thread "Question 343 about PRFs with fixed size key", Jan 2005.) 345 2.9 EAP authentication and fixed PRF key size 347 As described in the previous section, PRFs with a fixed key size 348 require a shared secret of exactly that size. A strict 349 interpretation of this text also means that such PRFs are unlikely to 350 be useful for EAP authentication, since [EAP] specifies that the MSK 351 is at least 64 octets (512 bits) long, while PRF_AES128_CBC requires 352 a 128-bit key. It is currently under discussion whether truncation 353 or padding should be allowed in the EAP case (where the security 354 implications of truncation are slightly different). 356 (References: Thread "Question about PRFs with fixed size key", Jan 357 2005.) 359 3. Keying and rekeying 361 3.1 Semantics of the CREATE_CHILD_SA exchange 363 Section 1.3's organization does not lead to clear understanding of 364 what is needed in which environment. The section can be reorganized 365 with subsections for each use of the CREATE_CHILD_SA exchange 366 (creating child SAs, rekeying IKE SAs, and rekeying child SAs.) 368 Further, specific parts of Section 3.1 can be clarified. These 369 include: 371 o It is not clear which SA to send in a rekeying a child SA. The 372 relevant sentence says "If this CREATE_CHILD_SA exchange is 373 rekeying an existing SA other than the IKE_SA, the leading N 374 payload of type REKEY_SA MUST identify the SA being rekeyed." That 375 can be clarified by adding "sender's inbound" before "SA being 376 rekeyed". 378 o The specific method for rekeying an IKE_SA is not described in the 379 section that describes the rekeying. This is described in Section 380 2.8. Relevant text from Section 2.8 can be moved here. 382 o Section 1.3 never mentions the REKEY_SA Notification, but it does 383 have a mandatory Notification payload when rekeying. The 384 CREATE_CHILD_SA exchange MUST include a REKEY_SA Notification 385 payload with an SPI field identifying the SA being rekeyed. 387 o The spec is partially wrong about the use of nonces in computing 388 keys for CHILD_SAs. Section 1.3 says "The nonces from the initial 389 exchange are used in computing the keys for the CHILD_SA." 390 However, that is not always true. It is only true for a CHILD_SA 391 created in the IKE_AUTH exchange. Thus, the sentence can be 392 ignored because the use of the nonces for computing the keys is 393 clear in Section 2.17. 395 The new Section 1.3 with subsections and the above changes might look 396 like this. 398 NEW-1.3 The CREATE_CHILD_SA Exchange 400 The CREATE_CHILD_SA Exchange is used to create new CHILD_SAs and 401 to rekey both IKE_SAs and CHILD_SAs. This exchange consists of a 402 single request/response pair, and some of its function was 403 referred to as a phase 2 exchange in IKEv1. It MAY be initiated 404 by either end of the IKE_SA after the initial exchanges are 405 completed. 407 All messages following the initial exchange are 408 cryptographically protected using the cryptographic algorithms 409 and keys negotiated in the first two messages of the IKE 410 exchange. These subsequent messages use the syntax of the 411 Encrypted Payload described in section 3.14. All subsequent 412 messages included an Encrypted Payload, even if they are 413 referred to in the text as "empty". For both messages in the 414 CREATE_CHILD_SA, the message following the header is encrypted 415 and the message including the header is integrity protected 416 using the cryptographic algorithms negotiated for the IKE_SA. 418 The CREATE_CHILD_SA is used for rekeying IKE_SAs and 419 CHILD_SAs. This section describes the first part of rekeying, 420 the creation of new SAs; Section 2.8 covers the mechanics of 421 rekeying, including moving traffic from old to new SAs and the 422 deletion of the old SAs. The two sections must be read together 423 to understand the entire process of rekeying. 425 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in 426 this section the term initiator refers to the endpoint 427 initiating this exchange. An implementation MAY refuse all 428 CREATE_CHILD_SA requests within an IKE_SA. 430 The CREATE_CHILD_SA request MAY optionally contain a KE payload 431 for an additional Diffie-Hellman exchange to enable stronger 432 guarantees of forward secrecy for the CHILD_SA. The keying 433 material for the CHILD_SA is a function of SK_d established 434 during the establishment of the IKE_SA, the nonces exchanged 435 during the CREATE_CHILD_SA exchange, and the Diffie-Hellman 436 value (if KE payloads are included in the CREATE_CHILD_SA 437 exchange). 439 If a CREATE_CHILD_SA exchange includes a KEi payload, at least 440 one of the SA offers MUST include the Diffie-Hellman group of 441 the KEi MUST be an element of the group the initiator expects 442 the responder to accept (additional Diffie-Hellman groups can be 443 proposed). If the responder rejects the Diffie-Hellman group of 444 the KEi payload, the responder MUST reject the request and 445 indicate its preferred Diffie-Hellman group in the 446 INVALID_KE_PAYLOAD Notification payload. In the case of such a 447 rejection, the CREATE_CHILD_SA exchange fails, and the initiator 448 SHOULD retry the exchange with a Diffie-Hellman proposal and KEi 449 in the group that the responder gave in the INVALID_KE_PAYLOAD. 451 NEW-1.3.1 Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange 453 A CHILD_SA may be created by sending a CREATE_CHILD_SA request. 454 The CREATE_CHILD_SA request for creating a new CHILD_SA is: 456 Initiator Responder 457 ----------- ----------- 458 HDR, SK {SA, Ni, [KEi], 459 TSi, TSr} --> 461 The initiator sends SA offer(s) in the SA payload, a nonce in 462 the Ni payload, optionally a Diffie-Hellman value in the KEi 463 payload, and the proposed traffic selectors for the proposed 464 CHILD_SA in the TSi and TSr payloads. 466 The CREATE_CHILD_SA response for creating a new CHILD_SA is: 468 <-- HDR, SK {SA, Nr, [KEr], 469 TSi, TSr} 471 The responder replies (using the same Message ID to respond) 472 with the accepted offer in an SA payload, and a Diffie-Hellman 473 value in the KEr payload if KEi was included in the request and 474 the selected cryptographic suite includes that group. 476 The traffic selectors for traffic to be sent on that SA are 477 specified in the TS payloads in the response, which may be a 478 subset of what the initiator of the CHILD_SA proposed. 480 NEW-1.3.2 Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange 482 The CREATE_CHILD_SA request for rekeying an IKE_SA is: 484 Initiator Responder 485 ----------- ----------- 486 HDR, SK {SA, Ni, [KEi]} --> 488 The initiator sends SA offer(s) in the SA payload, a nonce in 489 the Ni payload, and optionally a Diffie-Hellman value in the KEi 490 payload. New initiator and responder SPIs are supplied in the 491 SPI fields. 493 The CREATE_CHILD_SA response for rekeying an IKE_SA is: 495 <-- HDR, SK {SA, Nr, [KEr]} 497 The responder replies (using the same Message ID to respond) 498 with the accepted offer in an SA payload, and a Diffie-Hellman 499 value in the KEr payload if KEi was included in the request and 500 the selected cryptographic suite includes that group. 502 The new IKE_SA has its message counters set to 0, regardless of 503 what they were in the earlier IKE_SA. The window size starts at 504 1 for any new IKE_SA. 506 NEW-1.3.3 Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange 508 The CREATE_CHILD_SA request for rekeying a CHILD_SA is: 510 Initiator Responder 511 ----------- ----------- 512 HDR, SK {N, SA, Ni, [KEi], 513 TSi, TSr} --> 515 The initiator sends SA offer(s) in the SA payload, a nonce in 516 the Ni payload, optionally a Diffie-Hellman value in the KEi 517 payload, and the proposed traffic selectors for the proposed 518 CHILD_SA in the TSi and TSr payloads. When rekeying an existing 519 CHILD_SA, the leading N payload of type REKEY_SA MUST be 520 included and MUST identify the sender's inbound SA being 521 rekeyed. 523 The CREATE_CHILD_SA response for rekeying a CHILD_SA is: 525 <-- HDR, SK {SA, Nr, [KEr], 526 TSi, TSr} 528 The responder replies (using the same Message ID to respond) 529 with the accepted offer in an SA payload, and a Diffie-Hellman 530 value in the KEr payload if KEi was included in the request and 531 the selected cryptographic suite includes that group. 533 The traffic selectors for traffic to be sent on that SA are 534 specified in the TS payloadsin the response, which may be a 535 subset of what the initiator of the CHILD_SA proposed. 537 3.2 Rekeying the IKE_SA vs. reauthentication 539 Rekeying the IKE_SA and reauthentication are different concepts in 540 IKEv2. Rekeying the IKE_SA establishes new keys for the IKE_SA and 541 resets the Message ID counters, but it does not authenticate the 542 parties again (no AUTH or EAP payloads are involved). 544 While rekeying the IKE_SA may be important in some environments, 545 reauthentication (the verification that the parties still have access 546 to the long-term credentials) is often more important. 548 IKEv2 does not have any special support for reauthentication. 549 Reauthentication is done by creating a new IKE_SA from scratch (using 550 IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify 551 payloads), creating new CHILD_SAs within the new IKE_SA (without 552 REKEY_SA notify payloads), and finally deleting the old IKE_SA (which 553 deletes the old CHILD_SAs as well). 555 This means that reauthentication also establishes new keys for the 556 IKE_SA and CHILD_SAs. Therefore, while rekeying can be performed 557 more often than reauthentication, the situation where "authentication 558 lifetime" is shorter than "key lifetime" does not make sense. 560 While creation of a new IKE_SA can be initiated by either party 561 (initiator or responder in the original IKE_SA), the use of EAP 562 authentication and/or configuration payloads means in practice that 563 reauthentication has to be initiated by the same party as the 564 original IKE_SA. IKEv2 does not currently allow the responder to 565 request reauthentication in this case; however, there is ongoing work 566 to add this functionality [ReAuth]. 568 (References: "Reauthentication in IKEv2" thread, Oct/Nov 2004.) 570 3.3 SPIs when rekeying the IKE_SA 572 Section 2.18 says that "New initiator and responder SPIs are supplied 573 in the SPI fields". This refers to the SPI fields in the Proposal 574 structures inside the Security Association (SA) payloads, not the SPI 575 fields in the IKE header. 577 (References: Tom Stiemerling's mail "Rekey IKE SA", 2005-01-24. 578 Geoffrey Huang's reply, 2005-01-24.) 580 3.4 SPI when rekeying a CHILD_SA 582 Section 3.10.1 says that in REKEY_SA notifications, "The SPI field 583 identifies the SA being rekeyed." 585 Since CHILD_SAs always exist in pairs, there are two different SPIs. 586 The SPI placed in the REKEY_SA notification is the SPI the exchange 587 initiator would expect in inbound ESP or AH packets (just as in 588 Delete payloads). 590 3.5 Deleting SAs 592 It is not clear that SAs must be actively deleted. The text 593 sometimes says that SAs are "closed" when it means that the SAs are 594 actively deleted. Section 1.4 says "ESP and AH SAs always exist in 595 pairs, with one SA in each direction. When an SA is closed, both 596 members of the pair MUST be closed." It is important to note that SAs 597 that are closed need to be actively deleted with DELETE payloads. 599 4. Traffic selectors 601 4.1 Semantics of complex traffic selector payloads 603 As described in Section 3.13, the TSi/TSr payloads can include one or 604 more individual traffic selectors. 606 There is no requirement that TSi and TSr contain the same number of 607 individual traffic selectors. Thus, they are interpreted as follows: 608 a packet matches a given TSi/TSr if it matches at least one of the 609 individual selectors in TSi, and at least one of the individual 610 selectors in TSr. 612 For instance, the following traffic selectors: 614 TSi = ((17, 100, 192.0.1.66-192.0.1.66), 615 (17, 200, 192.0.1.66-192.0.1.66)) 616 TSr = ((17, 300, 0.0.0.0-255.255.255.255), 617 (17, 400, 0.0.0.0-255.255.255.255)) 619 would match UDP packets from 192.0.1.66 to anywhere, with any of the 620 four combinations of source/destination ports (100,300), (100,400), 621 (200,300), and (200, 400). 623 This implies that some types of policies may require several CHILD_SA 624 pairs. For instance, a policy matching only source/destination ports 625 (100,300) and (200,400), but not the other two combinations, cannot 626 be negotiated as a single CHILD_SA pair using IKEv2. 628 (References: "IKEv2 Traffic Selectors?" thread, Feb 2005.) 630 4.2 ICMP type/code in traffic selector payloads 632 The traffic selector types 7 and 8 can also refer to ICMP type and 633 code fields. As described in Section 3.13.1, "For the ICMP protocol, 634 the two one octet fields Type and Code are treated as a single 16 bit 635 integer (with Type in the most significant eight bits and Code in the 636 least significant eight bits) port number for the purposes of 637 filtering based on this field." 639 This encoding is quite clear. However, as both TSi and TSr are 640 always present, together they have two "start port" fields (one in 641 TSi and one in TSr) and two "end port" fields. Since ICMP messages 642 only have a single type/code field (instead of separate 643 source/destination ports, like TCP and UDP), there is some room for 644 confusion. 646 One sensible interpretation would be that in case of ICMP, the "start 647 port" fields in TSi and TSr must always be equal, and likewise for 648 the "end port" fields. 650 4.3 Mobility header in traffic selector payloads 652 Traffic selectors can use IP Protocol ID 135 to match the IPv6 653 mobility header [MIPv6]. However, the IKEv2 specification does not 654 define how to represent the "MH Type" field in traffic selectors. 656 At some point, it was expected that this will be defined in a 657 separate document later. However, [RFC2401bis] says that "For IKE, 658 the IPv6 mobility header message type (MH type) is placed in the most 659 significant eight bits of the 16 bit local "port" selector." 661 (References: Tero Kivinen's mail "Issue #86: Add IPv6 mobility header 662 message type as selector", 2003-10-14.) 664 4.4 Narrowing the traffic selectors 666 Section 2.9 describes how traffic selectors are negotiated when 667 creating a CHILD_SA. A more concise summary of the narrowing process 668 is presented below. 670 o If the responder's policy does not allow any part of the traffic 671 covered by TSi/TSr, it responds with TS_UNACCEPTABLE. 673 o If the responder's policy allows the entire set of traffic covered 674 by TSi/TSr, no narrowing is necessary, and the responder can 675 return the same TSi/TSr values. 677 o Otherwise, narrowing is needed. If the responder's policy allows 678 all traffic covered by TSi[1]/TSr[1] (the first traffic selectors 679 in TSi/TSr) but not entire TSi/TSr, the responder narrows to an 680 acceptable subset of TSi/TSr that includes TSi[1]/TSr[1]. 682 o If the responder's policy does not allow all traffic covered by 683 TSi[1]/TSr[1], but does allow some parts of TSi/TSr, it narrows to 684 an acceptable subset of TSi/TSr. 686 In the last two cases, there may be several subsets that are 687 acceptable (but their union is not); in this case, the responder 688 arbitrarily chooses one of them, and includes ADDITIONAL_TS_POSSIBLE 689 notification in the response. 691 4.5 SINGLE_PAIR_REQUIRED 693 The description of the SINGLE_PAIR_REQUIRED notify payload in 694 Sections 2.9 and 3.10.1 is not fully consistent. 696 We do not attempt to describe this payload in this document either, 697 since it is expected that most implementations will not have policies 698 that require separate SAs for each address pair. 700 Thus, if only some part (or parts) of the TSi/TSr proposed by the 701 initiator is (are) acceptable to the responder, most responders 702 should simply narrow TSi/TSr to an acceptable subset (as described in 703 the last two paragraphs of Section 2.9), rather than use 704 SINGLE_PAIR_REQUIRED. 706 4.6 Traffic selectors violating own policy 708 Section 2.9 describes traffic selector negotiation in great detail. 709 One aspect of this negotiation that may need some clarification is 710 that when creating a new SA, the initiator should not propose traffic 711 selectors that violate its own policy. If this rule is not followed, 712 valid traffic may be dropped. 714 This is best illustrated by an example. Suppose that host A has a 715 policy whose effect is that traffic to 192.0.1.66 is sent via host B 716 encrypted using AES, and traffic to all other hosts in 192.0.1.0/24 717 is also sent via B, but must use 3DES. Suppose also that host B 718 accepts any combination of AES and 3DES. 720 If host A now proposes an SA that uses 3DES, and includes TSr 721 containing (192.0.1.0-192.0.1.0.255), this will be accepted by host 722 B. Now, host B can also use this SA to send traffic from 192.0.1.66, 723 but those packets will be dropped by A since it requires the use of 724 AES for those traffic. Even if host A creates a new SA only for 725 192.0.1.66 that uses AES, host B may freely continue to use the first 726 SA for the traffic. In this situation, when proposing the SA, host A 727 should have followed its own policy, and included a TSr containing 728 ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead. 730 In general, if (1) the initiator makes a proposal "for traffic X 731 (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator 732 does not actually accept traffic X' with SA, and (3) the initiator 733 would be willing to accept traffic X' with some SA' (!=SAi), valid 734 traffic can be unnecessarily dropped since the responder can apply 735 either SA or SA' to traffic X'. 737 (References: "Question about "narrowing" ..." thread, Feb 2005. 738 "IKEv2 needs a "policy usage mode"..." thread, Feb 2005. "IKEv2 739 Traffic Selectors?" thread, Feb 2005. "IKEv2 traffic selector 740 negotiation examples", 2004-08-08.) 742 5. Configuration payloads 744 5.1 Length of configuration attribute type field 746 In Section 3.15.1, Figure 23 shows that the length of the "Attribute 747 Type" field is 15 bits, while the text below the figure says the 748 length is 7 bits. 750 The figure is correct, the field is 15 bits. 752 (References: Tero Kivinen's mail "Comments to the 753 draft-ietf-ipsec-ikev2-11.txt", 2003-11-09. Yoav Nir's mail "Will 754 ikev2-16 be the charm?", 2004-09-23. Charlie Kaufman's 755 mail"draft-ietf-ipsec-ikev2-17.txt", 2004-10-04. It is expected that 756 this issue will be fixed during the "Authors' 48 hours" before the 757 RFC is published.) 759 5.2 Requesting any INTERNAL_IP4/IP6_ADDRESS 761 When describing the INTERNAL_IP4/IP6_ADDRESS attributes, Section 762 3.15.1 says that "In a request message, the address specified is a 763 requested address (or zero if no specific address is requested)". 764 The question here is that does "zero" mean an address "0.0.0.0" or a 765 zero length string? 767 Earlier, the same section also says that "If an attribute in the 768 CFG_REQUEST Configuration Payload is not zero length it is taken as a 769 suggestion for that attribute". Also, the table of configuration 770 attributes shows that the length of INTERNAL_IP4_ADDRESS is either "0 771 or 4 octets", and likewise, INTERNAL_IP6_ADDRESS is either "0 or 17 772 octets". 774 Thus, if the client does not request a specific address, it includes 775 a zero-length INTERNAL_IP4/IP6_ADDRESS attribute, not an attribute 776 containing an all-zeroes address. The example in 2.19 is thus 777 incorrect, since it shows the attribute as 778 "INTERNAL_ADDRESS(0.0.0.0)". 780 However, since the value is only a suggestion, implementations are 781 recommended to ignore suggestions they do not accept; or in other 782 words, treat the same way a zero-length INTERNAL_IP4_ADDRESS, 783 "0.0.0.0", and any other addresses the implementation does not 784 recognize as a reasonable suggestion. 786 5.3 INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET 788 Section 3.15.1 describes the INTERNAL_IP4_SUBNET as "The protected 789 sub-networks that this edge-device protects. This attribute is made 790 up of two fields; the first being an IP address and the second being 791 a netmask. Multiple sub-networks MAY be requested. The responder 792 MAY respond with zero or more sub-network attributes." 793 INTERNAL_IP6_SUBNET is defined in a similar manner. 795 This raises two questions: first, since this information is usually 796 included in the TSr payload, what functionality does this attribute 797 add? And second, what does this attribute mean in CFG_REQUESTs? 799 For the first question, there seem to be two sensible 800 interpretations. Clearly TSr (in IKE_AUTH or CREATE_CHILD_SA 801 response) indicates which subnets are accessible through the SA that 802 was just created. 804 The first interpretation of the INTERNAL_IP4/6_SUBNET attributes is 805 that they indicate additional subnets that can be reached through 806 this gateway, but need a separate SA. According to this 807 interpretation, the INTERNAL_IP4/6_SUBNET attributes are useful 808 mainly when they contain addresses not included in TSr. 810 The second interpretation is that the INTERNAL_IP4/6_SUBNET 811 attributes express the gateway's policy about what traffic should be 812 sent through the gateway. The client can choose whether other 813 traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is sent 814 through the gateway or directly the destination. According to this 815 interpretation, the attributes are useful mainly when TSr contains 816 addresses not included in the INTERNAL_IP4/6_SUBNET attributes. 818 These two interpretations are not totally incompatible: in both 819 cases, they suggest that traffic to the addresses listed in the 820 INTERNAL_IP4/6_SUBNET attributes should be sent via this gateway 821 (and, of course, the packets have to be sent over some SA whose 822 traffic selectors cover the address in question). 824 A couple of examples are given below. For instance, if there are two 825 subnets, 192.0.1.0/26 and 192.0.2.0/24, and the client's request 826 contains the following: 828 CP(CFG_REQUEST) = 829 INTERNAL_IP4_ADDRESS() 830 TSi = (0, 0-65536, 0.0.0.0-255.255.255.255) 831 TSr = (0, 0-65536, 0.0.0.0-255.255.255.255) 833 Then a valid response could be the following (in which TSr and 834 INTERNAL_IP4_SUBNET contain the same information): 836 CP(CFG_REPLY) = 837 INTERNAL_IP4_ADDRESS(192.0.1.234) 838 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 839 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 840 TSi = (0, 0-65536, 192.0.1.234-192.0.1.234) 841 TSr = ((0, 0-65536, 192.0.1.0-192.0.1.63), 842 (0, 0-65536, 192.0.2.0-192.0.2.255)) 844 In these cases, the INTERNAL_IP4_SUBNET does not really carry any 845 useful information. Another possible reply would have been this: 847 CP(CFG_REPLY) = 848 INTERNAL_IP4_ADDRESS(192.0.1.234) 849 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 850 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 851 TSi = (0, 0-65536, 192.0.1.234-192.0.1.234) 852 TSr = (0, 0-65536, 0.0.0.0-255.255.255.255) 854 This would mean that the client can send all its traffic through the 855 gateway, but the gateway does not mind if the client sends traffic 856 not included by INTERNAL_IP4_SUBNET directly to the destination 857 (without going through the gateway). 859 A different situation arises if the gateway has a policy that 860 requires the traffic for the two subnets to be carried in separate 861 SAs. Then a response like this would indicate to the client that if 862 it wants access to the second subnet, it needs to create a separate 863 SA: 865 CP(CFG_REPLY) = 866 INTERNAL_IP4_ADDRESS(192.0.1.234) 867 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 868 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 869 TSi = (0, 0-65536, 192.0.1.234-192.0.1.234) 870 TSr = (0, 0-65536, 192.0.1.0-192.0.1.63) 872 INTERNAL_IP4_SUBNET can also be useful if the client's TSr included 873 only part of the address space. For instance, if the client requests 874 the following: 876 CP(CFG_REQUEST) = 877 INTERNAL_IP4_ADDRESS() 878 TSi = (0, 0-65536, 0.0.0.0-255.255.255.255) 879 TSr = (0, 0-65536, 192.0.2.155-192.0.2.155) 881 Then the gateway's reply could be this: 883 CP(CFG_REPLY) = 884 INTERNAL_IP4_ADDRESS(192.0.1.234) 885 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 886 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 887 TSi = (0, 0-65536, 192.0.1.234-192.0.1.234) 888 TSr = (0, 0-65536, 192.0.2.155-192.0.2.155) 890 It is less clear what the attributes mean in CFG_REQUESTs, and 891 whether other lengths than zero make sense in this situation (but for 892 INTERNAL_IP6_SUBNET, zero length is not allowed at all!). Currently 893 this document recommends that implementations should not include 894 INTERNAL_IP4_SUBNET or INTERNAL_IP6_SUBNET attributes in 895 CFG_REQUESTs. 897 For the IPv4 case, this document recommends using only netmasks 898 consisting of some amount of "1" bits followed by "0" bits; for 899 instance, "255.0.255.0" would not be a valid netmask for 900 INTERNAL_IP4_SUBNET. 902 (References: Tero Kivinen's mail "Intent of couple of attributes in 903 Configuration Payload in IKEv2?", 2004-11-19. Srinivasa Rao 904 Addepalli's mail "INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET in 905 IKEv2", 2004-09-10. Yoav Nir's mail "Re: New I-D: IKEv2 906 Clarifications and Implementation Guidelines", 2005-02-07.) 908 5.4 INTERNAL_IP4_NETMASK 910 Section 3.15.1 defines the INTERNAL_IP4_NETMASK attribute, and says 911 that "The internal network's netmask. Only one netmask is allowed in 912 the request and reply messages (e.g., 255.255.255.0) and it MUST be 913 used only with an INTERNAL_IP4_ADDRESS attribute". 915 However, it is not clear what exactly this attribute means, as the 916 concept of "netmask" is not very well defined for point-to-point 917 links (unlike multi-access links, where it means "you can reach hosts 918 inside this netmask directly using layer 2, instead of sending 919 packets via a router"). 921 One possible interpretation would be that the host is given a whole 922 block of IP addresses instead of a single address. This is also what 923 Framed-IP-Netmask does in [RADIUS] and the IPCP "subnet mask" 924 extension does in PPP [IPCPSubnet]. This interpretation would also 925 work nicely with IPv6 (see the following section). 927 However, one IKEv2 guru assured the authors that this interpretation 928 is not correct. Section 3.15.1 also says that multiple addresses are 929 assigned using multiple INTERNAL_IP4_ADDRESS attributes. 931 Currently, this document's interpretation is the following: 933 o INTERNAL_IP4_NETMASK in a CFG_REPLY means exactly the same thing 934 as INTERNAL_IP4_SUBNET containing the same information (see the 935 previous section for description of INTERNAL_IP4_SUBNET). 937 o INTERNAL_IP4_NETMASK does not make sense for CFG_REQUESTs, and the 938 example in Section 2.19 is incorrect in this sense. (Another 939 interpretation would be that by sending, for instance, the 940 combination of INTERNAL_IP4_ADDRESS(192.0.2.0) and 941 INTERNAL_IP4_NETMASK(255.255.255.0), the client is asking to be 942 assigned one IP address from the network 192.0.2.0/24. However, 943 this interpretation is not supported by the IKEv2 spec.) 945 This interpretation is not yet settled; and it would imply that the 946 whole attribute is totally unnecessary. 948 Yet another possible interpretation would be that 949 INTERNAL_IP4_NETMASK indicates a broadcast address, meaning that if a 950 client sends a packet to this address, the gateway will decrypt it 951 and send copies to all other VPN clients in that address range. 952 However, no implementation is known to do this, and there is nothing 953 in the IKEv2 spec that would support this interpretation. 955 Fortunately, Section 4 clearly says that a minimal implementation 956 does not need to include or understand the INTERNAL_IP4_NETMASK 957 attribute, and thus this document recommends that implementations 958 should not use the INTERNAL_IP4_NETMASK attribute at all. 960 (References: Charlie Kaufman's mail "RE: Proposed Last Call based 961 revisions to IKEv2", 2004-05-27. Email discussion with Tero Kivinen, 962 Jan 2005. Yoav Nir's mail "Re: New I-D: IKEv2 Clarifications and 963 Implementation Guidelines", 2005-02-07.) 965 5.5 Configuration payloads for IPv6 967 IKEv2 also defines configuration payloads for IPv6. However, they 968 are based on the corresponding IPv4 payloads, and do not fully follow 969 the "normal IPv6 way of doing things". 971 A client can be assigned an IPv6 address using the 972 INTERNAL_IP6_ADDRESS configuration payload. Presumably, the idea was 973 that a minimal exchange would look something like this: 975 CP(CFG_REQUEST) = 976 INTERNAL_IP6_ADDRESS() 977 INTERNAL_IP6_DNS() 978 TSi = (0, 0-65536, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 979 TSr = (0, 0-65536, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 981 CP(CFG_REPLY) = 982 INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/?) 983 INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) 984 TSi = (0, 0-65536, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) 985 TSr = (0, 0-65536, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 987 In particular, IPv6 stateless autoconfiguration or router 988 advertisement messages are not used; neither is neighbor discovery. 990 While this approach is reasonably simple, it has some limitations: 991 IPsec tunnels configured using IKEv2 are not fully-featured 992 "interfaces" in the IPv6 addressing architecture [IPv6Addr] sense. 993 In particular, they do not necessarily have link-local addresses, and 994 this may complicate the use of protocols that assume them, such as 995 [MLDv2]. (Whether they are called "interfaces" in some particular 996 operating system is a different issue.) 998 (References: "VPN remote host configuration IPv6 ?" thread, May 999 2004.) 1001 5.6 INTERNAL_IP6_ADDRESS prefix length 1003 Earlier versions of the IKEv2 draft had an INTERNAL_IP6_NETMASK 1004 attribute corresponding to INTERNAL_IP4_NETMASK, but this was deleted 1005 when the prefix length field was added to the INTERNAL_IP6_ADDRESS 1006 attribute. Thus, it seems logical to assume that their purpose would 1007 be similar; however, this is far from obvious. 1009 The draft quite clearly says that the client is assigned an IPv6 1010 address using the INTERNAL_IP6_ADDRESS attribute. However, as with 1011 the netmask in IPv4, it is not clear what the prefix length here 1012 means. 1014 Again, one possible interpretation is that a prefix length smaller 1015 than 128 in a CFG_REPLY means that the client is assigned a whole 1016 block of IPv6 addresses. This would be in line with the IPv6 1017 addressing architecture in general, and with, e.g., the 1018 Framed-IPv6-Prefix attribute in [RADIUS6]. However, the previous 1019 section rejected this interpretation for IPv4, so it would seem 1020 strange to adopt it only for IPv6. 1022 Thus, if we assume that INTERNAL_IP4_NETMASK and the prefix length in 1023 INTERNAL_IP6_ADDRESS have the same meaning, and the reasoning in the 1024 previous section is correct, then a CFG_REPLY containing a prefix 1025 length smaller than 128 has the same purpose as INTERNAL_IP6_SUBNET. 1027 However, CFG_REQUESTs are more complicated. It seems that a 1028 CFG_REQUEST message that requests a specific IPv6 address (usually an 1029 address this client was using earlier) should have prefix length 128. 1030 But what do other prefix lengths mean in CFG_REQUESTs? 1032 Section 3.15.1 says that "With IPv6, a requestor MAY supply the low 1033 order address bytes it wants to use": presumably the prefix length 1034 tells how many low order bits there are (i.e., if the prefix length 1035 is X, there requester supplies 128-X low order address bits). 1036 However, this is quite confusing: if, say, a prefix length 126 means 1037 that "I want to use these 128-126=2 low order bits", why does prefix 1038 length 128 mean that "I want to use these 128 low order bits"? 1040 Another interpretation is that instead of "low order", the draft 1041 should have said "high order", and thus a prefix length smaller than 1042 128 means "I'd like to get an address from this subnet". 1044 Given this very confusing discussion, this document recommends that 1045 implementations should not use other INTERNAL_IP6_ADDRESS prefix 1046 lengths than 128. 1048 5.7 INTERNAL_IP6_NBNS 1050 Section 3.15.1 defines the INTERNAL_IP6_NBNS attribute for sending 1051 the IPv6 address of NetBIOS name servers. 1053 However, NetBIOS is not defined for IPv6, and probably never will be. 1054 Thus, this attribute most likely does not make much sense. 1056 (Pointed out by Bernard Aboba in the IP Configuration Security (ICOS) 1057 BoF at IETF62.) 1059 6. Miscellaneous issues 1060 6.1 Diffie-Hellman for first CHILD_SA 1062 Section 1.2 shows that IKE_AUTH messages do not contain KEi/KEr or 1063 Ni/Nr payloads. This implies that the SA payload in IKE_AUTH 1064 exchange cannot contain Transform Type 4 (Diffie-Hellman Group) with 1065 any other value than NONE. 1067 6.2 Extended Sequence Numbers (ESN) transform 1069 The description of the ESN transform in Section 3.3 has be proved 1070 difficult to understand. When the ESN transform is included, it has 1071 the following meaning: 1073 o A proposal containing one ESN transform with value 0 means "do not 1074 use extended sequence numbers". 1076 o A proposal containing one ESN transform with value 1 means "use 1077 extended sequence numbers". 1079 o A proposal containing two ESN transforms with values 0 and 1 means 1080 "I support both normal and extended sequence numbers, you choose". 1081 (Obviously this case is only allowed in requests; the response 1082 will contain only one ESN transform.) 1084 In most cases, the exchange initiator will include either the first 1085 or third alternative in its SA payload. The second alternative is 1086 rarely useful for the initiator: it means that using normal sequence 1087 numbers is not acceptable (so if the responder does not support ESNs, 1088 the exchange will fail with NO_PROPOSAL_CHOSEN). 1090 Section 3.3.2 also says that "If Transform Type 5 is not included in 1091 a proposal, use of Extended Sequence Numbers is assumed". Or in 1092 other words, omitting the ESN transform means the same thing as 1093 including one ESN transform with value 1. 1095 This choice of default value is somewhat counterintuitive and as 1096 described above, rarely useful. There is ongoing discussion about 1097 making including the ESN transform mandatory, thus removing this 1098 illogical default value. 1100 (References: "Technical change needed to IKEv2 before publication" 1101 and "STRAW POLL: Dealing with the ESN negotiation interop issuein 1102 IKEv2" threads, March 2005.) 1104 6.3 Matching ID_IPV4_ADDR and ID_IPV6_ADDR 1106 When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr 1107 payloads, IKEv2 does not require this address to match the address in 1108 the IP header (of IKEv2 packets), or anything in the TSi/TSr 1109 payloads. The contents of IDi/IDr is used purely to fetch the policy 1110 and authentication data related to the other party. 1112 (References: "Identities types IP address,FQDN/user FQDN and DN and 1113 its usage in pershared key authentication" thread, Jan 2005.) 1115 6.4 Relationship of IKEv2 to RFC2401bis 1117 The IKEv2 document refers to [RFC2401bis], but it never makes clear 1118 what the exact relationship is. That is probably because there is no 1119 exact relationship. However, the IKEv2 document could state this 1120 explicitly. 1122 IKEv2 can be used with either [RFC2401] or [RFC2401bis], except in 1123 places that are only covered by [RFC2401bis]. The areas specific to 1124 [RFC2401bis] are ECN (Section 2.24), fragmentation control (Section 1125 3.10), and the use of opaque ports in traffic selectors (Section 1126 3.13.1). IKEv2 allows the creation of a single SA that has multiple 1127 protocols when being used with [RFC2401]; this is not allowed in 1128 [RFC2401bis]. 1130 6.5 Reducing the window size 1132 In IKEv2, the window size is assumed to be a (possibly configurable) 1133 property of a particular implementation, and is not related to 1134 congestion control (unlike the window size in TCP, for instance). 1136 In particular, there is no way to reduce the window size of an 1137 existing IKE_SA. However, when rekeying an IKE_SA, the new IKE_SA 1138 starts with window size 1 until it is explicitly increased by sending 1139 a new SET_WINDOW_SIZE notification. 1141 6.6 Minimum size of nonces 1143 Section 2.10 says that "Nonces used in IKEv2 MUST be randomly chosen, 1144 MUST be at least 128 bits in size, and MUST be at least half the key 1145 size of the negotiated prf." 1147 However, the initiator chooses the nonce before the outcome of the 1148 negotiation is known. In this case, the nonce has to be long enough 1149 for all the PRFs being proposed. 1151 6.7 Initial zero octets on port 4500 1153 It is not clear whether a peer sending an IKE_SA_INIT request on port 1154 4500 should include the initial four zero octets. Section 2.23 talks 1155 about how to upgrade to tunneling over port 4500 after message 2, but 1156 it does not say what to do if message 1 is sent on port 4500. 1158 IKE MUST listen on port 4500 as well as port 500. 1160 [...] 1162 The IKE initiator MUST check these payloads if present and if 1163 they do not match the addresses in the outer packet MUST tunnel 1164 all future IKE and ESP packets associated with this IKE_SA over 1165 UDP port 4500. 1167 To tunnel IKE packets over UDP port 4500, the IKE header has four 1168 octets of zero prepended and the result immediately follows the 1169 UDP header. [...] 1171 The very beginning of Section 2 says "... though IKE messages may 1172 also be received on UDP port 4500 with a slightly different format 1173 (see section 2.23)." 1175 That "slightly different format" is only described in discussing what 1176 to do after changing to port 4500. However, [RFC3948] shows clearly 1177 the format has the initial zeros even for initiators on port 4500. 1178 Furthermore, without the initial zeros, the processing engine cannot 1179 determine whether the packet is an IKE packet or an ESP packet. 1181 Thus, all packets sent on port 4500 need the four zero prefix; 1182 otherwise, the receiver won't know how to handle them. 1184 6.8 SPI values in IKE_SA_INIT exchange 1186 Normal IKE messages include the initiator's and responder's SPIs, 1187 both of which are non-zero, in the IKE header. However, there are 1188 some corner cases where the IKEv2 specification is not fully 1189 consistent about what values should be used. 1191 First, Section 3.1 says that the Responder's SPI "...MUST NOT be zero 1192 in any other message" (than the first message of the IKE_SA_INIT 1193 exchange). However, the figure in Section 2.6 shows the second 1194 IKE_SA_INIT message as "HDR(A,0), N(COOKIE)", contradicting the text 1195 in 3.1. 1197 Since the responder's SPI identifies security-related state held by 1198 the responder, and in this case no state is created, sending a zero 1199 value seems reasonable. 1201 Second, in addition to cookies, there are several other cases when 1202 the IKE_SA_INIT exchange does not result in the creation of an IKE_SA 1203 (for instance, INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). What 1204 responder SPI value should be used in the IKE_SA_INIT response in 1205 this case? 1207 Since the IKE_SA_INIT request always has a zero responder SPI, the 1208 value will not be actually used by the initiator. Thus, we think 1209 sending a zero value is correct also in this case. 1211 6.9 SPI values for messages outside of an IKE_SA 1213 The IKEv2 specification does not say what SPI values should be used 1214 for Informational requests sent outside of an IKE_SA. 1216 There seem to be two cases when such a message can be sent: 1217 INVALID_IKE_SPI and INVALID_SPI notifications. Especially in the 1218 latter case, no meaningful IKE SPI values are available. 1220 A strict interpretation of the specification would require the sender 1221 to invent garbage values for the SPI fields. However, we think this 1222 was not the intention, and using zero values is acceptable. 1224 6.10 Protocol ID/SPI fields in Notify payloads 1226 Section 3.10 says that the Protocol ID field in Notify payloads "For 1227 notifications which do not relate to an existing SA, this field MUST 1228 be sent as zero and MUST be ignored on receipt". However, the 1229 specification does not clearly say which notifications are related to 1230 existing SAs and which are not. 1232 Since the main purpose of the Protocol ID field is to specify the 1233 type of the SPI, our interpretation is that the Protocol ID field 1234 should be non-zero only when the SPI field is non-empty. 1236 There are currently only two notifications where this is the case: 1237 INVALID_SELECTORS and REKEY_SA. 1239 6.11 INVALID_IKE_SPI 1241 Section 3.10.1 says that the INVALID_IKE_SPI notification "indicates 1242 an IKE message was received with an unrecognized destination SPI. 1243 This usually indicates that the recipient has rebooted and forgotten 1244 the existence of an IKE_SA." 1246 The text does not say whether the SPI value should be included in the 1247 notification. However, it is clear that the notification will be 1248 useful to the recipient only if it can find the IKE_SA somehow, so 1249 the SPI should be included. 1251 This still leaves two questions open: which SPI(s) should be 1252 included, and how it (or they) should be sent. For the first 1253 question, the alternatives are the unrecognized destination SPI, the 1254 source SPI (which presumably would be more useful for the recipient), 1255 or both. For the second question, the SPI(s) could be placed in the 1256 SPI field(s) in the IKE header, the SPI field in the Notify payload, 1257 or the Notification Data field. 1259 In the case of another related notification, INVALID_SPI, the 1260 situation is clearer: there is only a single SPI, and the text 1261 explicitly says that the SPI is sent as Notification Data (since the 1262 notification is not about an existing SA, the SPI field in the Notify 1263 payload is not used; and obviously the value cannot be placed in the 1264 IKE header). 1266 Since the INVALID_IKE_SPI notification is sent outside of an IKE_SA, 1267 and it is not about an existing SA, it seems that using Notification 1268 Data would be the logical choice. However, this issue needs more 1269 discussion and we do not yet propose any solution in this document. 1271 6.12 Which message should contain INITIAL_CONTACT 1273 The description of the INITIAL_CONTACT notification in Section 3.10.1 1274 says that "This notification asserts that this IKE_SA is the only 1275 IKE_SA currently active between the authenticated identities". 1276 However, neither Section 2.4 nor 3.10.1 says in which message this 1277 payload should be placed. 1279 The text does talk about authenticated identities, so it seems the 1280 notification cannot be sent before both endpoints have been 1281 authenticated. Thus, the possible places are the last IKE_AUTH 1282 response message and a separate Informational exchange. 1284 Based on how this was implemented in IKEv1, it seems the intent was 1285 to use a separate Informational exchange. 1287 7. Status of the clarifications 1289 This document is work-in-progress, and it contains both relatively 1290 stable and finished parts, and other parts that are incomplete or 1291 even incorrect. To help the reader in deciding how much weight 1292 should be given to each clarification, this section contains our 1293 opinions about which parts we believe to are stable, and which are 1294 likely to change in future versions. 1296 Those clarifications believed to be correct and without controversy 1297 are marked with three asterisks (***); those where the clarification 1298 is known to be incomplete and/or there is disagreement about what the 1299 correct interpretation is are marked with one asterisk (*). The 1300 clarifications marked with two asterisks (**) are somewhere between 1301 the extremes. 1303 2. Authentication 1304 2.1 Data included in AUTH payload calculation *** 1305 2.2 Hash function for RSA signatures *** 1306 2.3 Encoding method for RSA signatures *** 1307 2.4 Identification type for EAP *** 1308 2.5 Identity for policy lookups when using EAP *** 1309 2.6 EAP authentication and the AUTH payload *** 1310 2.7 Certificate encoding types *** 1311 2.8 Shared key authentication and fixed PRF key size ** 1312 2.9 EAP authentication and fixed PRF key size * 1313 3. Keying and rekeying 1314 3.1 Semantics of the CREATE_CHILD_SA exchange * 1315 3.2 Rekeying the IKE_SA vs. reauthentication ** 1316 3.3 SPIs when rekeying the IKE_SA *** 1317 3.4 Which SPI to use in REKEY_SA *** 1318 3.5 Deleting SAs ** 1319 4. Traffic selectors 1320 4.1 Semantics of complex traffic selector payloads *** 1321 4.2 ICMP type/code in traffic selector payloads *** 1322 4.3 Mobility header in traffic selector payloads *** 1323 4.4 Narrowing the traffic selectors *** 1324 4.5 SINGLE_PAIR_REQUIRED ** 1325 4.6 Traffic selectors violating own policy * 1326 5. Configuration payloads 1327 5.1 Length of configuration attribute type field *** 1328 5.2 Requesting any INTERNAL_IP4/IP6_ADDRESS *** 1329 5.3 INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET ** 1330 5.4 INTERNAL_IP4_NETMASK ** 1331 5.5 Configuration payloads for IPv6 * 1332 5.6 INTERNAL_IP6_ADDRESS prefix length * 1333 5.7 INTERNAL_IP6_NBNS *** 1334 6. Miscellaneous issues 1335 6.1 Diffie-Hellman for first CHILD_SA *** 1336 6.2 Extended Sequence Numbers (ESN) transform ** 1337 6.3 Matching ID_IPV4_ADDR and ID_IPV6_ADDR *** 1338 6.4 Relationship of IKEv2 to RFC2401bis ** 1339 6.5 Reducing the window size ** 1340 6.6 Minimum size of nonces *** 1341 6.7 Initial zero octets on port 4500 *** 1342 6.8 SPI values in IKE_SA_INIT exchange ** 1343 6.9 SPI values for messages outside of an IKE_SA * 1344 6.10 Protocol ID/SPI fields in Notify payloads ** 1345 6.11 INVALID_IKE_SPI * 1346 6.12 Which message should contain INITIAL_CONTACT ** 1348 Future versions of this document will, of course, change these 1349 estimates (and changes in both directions are possible, though 1350 hopefully it's more towards higher confidence). 1352 8. Implementation mistakes 1354 Some implementers at the first IKEv2 bakeoff didn't do everything 1355 correctly. This may seem like an obvious statement, but it is 1356 probably useful to list a few things that were clear in the document 1357 and not needing clarification, that some implementors didn't do. All 1358 of these things caused interoperability problems. 1360 o Some implementations continued to send traffic on a CHILD_SA after 1361 it was rekeyed, even after receiving an DELETE payload. 1363 o After rekeying an IKE_SA, some implementations did not reset their 1364 message counters to zero. One set the counter to 2, another did 1365 not reset the counter at all. 1367 o Some implementations could only handle a single pair of traffic 1368 selectors, or would only process the first pair in the proposal. 1370 9. Open issues 1372 This section lists issues that this document probably should address, 1373 but has not done so yet. 1375 o In the traffic selector discussion, we need to come up with better 1376 wording for the "sender's inbound" SAs. Is that traffic that is 1377 being sent to the sender, or traffic being sent from the sender? 1379 o Many of the configuration payload issues in this draft are still 1380 far from clear. These need to be resolved before implementers can 1381 feel assured of creating interoperable implementations. 1383 o There may need to be more text about deleting an old SA after 1384 rekeying is finished. 1386 o The text about sending a DELETE for only one direction of an SA 1387 (and the responder sending the DELETE for the other direction of 1388 the SA in its response) doesn't explain the logic, and doesn't say 1389 why you should not send DELETEs for both directions of the SA. We 1390 need to add a description of the race condition if one side 1391 deletes both SAs at once. 1393 o When the document uses the term "original initiator" (or similar 1394 terms), it is not clear whether or not that term also applies to 1395 the side that originates an rekeying of the IKE_SA. That is, if 1396 Alice starts the first IKE_SA, but then Bob rekeys the IKE_SA, is 1397 the "original initiator" from that point on now Bob, or is it 1398 still Alice? Also, if it is Bob, at what exact point does it 1399 become Bob? This needs to be cleared up on a case-by-case basis 1400 throughout the document. 1402 o It would be very useful to have actual examples of certificate 1403 type 12 (hash and URL of X.509 certificates) and type 13 (hash and 1404 URL of X.509 bundle). 1406 o The message IDs of IKE_SA_INIT messages is unclear if there are 1407 cookies followed by INVALID_KE_PAYLOAD. See "Question about 1408 N(COOKIE) and N(INVALID_KE_PAYLOAD) combination" thread, Oct 2004. 1409 This definitely needs to be clarified. 1411 o There is some confusion on when to emit and process 1412 INITIAL_CONTACT payloads. References: Michael Richardson's mail 1413 "Initial Contact Messages", 2004-12-05. Paul Hoffman's reply, 1414 2004-12-05. Tero Kivinen's reply, 2004-12-07. "Replicated 1415 identities" thread in Jan 2005.) It is not clear if there is an 1416 interoperability issue because reacting to INITIAL_CONTACT is 1417 optional, but this should be cleared up. 1419 10. Security considerations 1421 This document does not introduce any new security considerations to 1422 IKEv2. If anything, clarifying complex areas of the specification 1423 can reduce the likelihood of implementation problems that may have 1424 security implications. 1426 11. IANA considerations 1428 This document does not change or create any IANA-registered values. 1430 12. Acknowledgments 1432 This document is mainly based on conversations on the IPsec WG 1433 mailing list. The authors would especially like to thank Bernard 1434 Aboba, Jari Arkko, Vijay Devarapalli, William Dixon, Mika 1435 Joutsenvirta, Charlie Kaufman, Tero Kivinen, Yoav Nir, and Michael 1436 Richardson for their contributions. 1438 In addition, the authors would like to thank all the participants of 1439 the first public IKEv2 bakeoff, held in Santa Clara in February 2005, 1440 for their questions and proposed clarifications. 1442 13. References 1444 13.1 Normative References 1446 [IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 1447 Protocol", draft-ietf-ipsec-ikev2-17 (work in progress), 1448 September 2004. 1450 [IKEv2ALG] 1451 Schiller, J., "Cryptographic Algorithms for use in the 1452 Internet Key Exchange Version 2", 1453 draft-ietf-ipsec-ikev2-algorithms-05 (work in progress), 1454 April 2004. 1456 [PKCS1v20] 1457 Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography 1458 Specifications Version 2.0", RFC 2437, October 1998. 1460 [PKCS1v21] 1461 Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1462 Standards (PKCS) #1: RSA Cryptography Specifications 1463 Version 2.1", RFC 3447, February 2003. 1465 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1466 Internet Protocol", RFC 2401, November 1998. 1468 [RFC2401bis] 1469 Kent, S. and K. Seo, "Security Architecture for the 1470 Internet Protocol", draft-ietf-ipsec-rfc2401bis-05 (work 1471 in progress), December 2004. 1473 13.2 Informative References 1475 [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 1476 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1477 3748, June 2004. 1479 [EAPKey] Aboba, B., Simon, D., Arkko, J., Eronen, P. and H. 1480 Levkowetz, "Extensible Authentication Protocol (EAP) Key 1481 Management Framework", draft-ietf-eap-keying-04 (work in 1482 progress), November 2004. 1484 [IPCPSubnet] 1485 Cisco Systems, Inc., "IPCP Subnet Mask Support 1486 Enhancements", 1487 http://www.cisco.com/univercd/cc/td/doc/product/software/i 1488 os121/121newft/121limit/121dc/121dc3/ipcp_msk.htm, January 1489 2003. 1491 [IPv6Addr] 1492 Hinden, R. and S. Deering, "Internet Protocol Version 6 1493 (IPv6) Addressing Architecture", RFC 3513, April 2004. 1495 [MIPv6] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support 1496 in IPv6", RFC 3775, June 2004. 1498 [MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery 1499 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1501 [NAI] Aboba, B. and M. Beadles, "The Network Access Identifier", 1502 RFC 2486, January 1999. 1504 [NAIbis] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The 1505 Network Access Identifier", 1506 draft-ietf-radext-rfc2486bis-03 (work in progress), 1507 November 2004. 1509 [RADEAP] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1510 Dial In User Service) Support For Extensible 1511 Authentication Protocol (EAP)", RFC 3579, September 2003. 1513 [RADIUS] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 1514 "Remote Authentication Dial In User Service (RADIUS)", RFC 1515 2865, June 2000. 1517 [RADIUS6] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 1518 3162, August 2001. 1520 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1521 Requirement Levels", RFC 2119, March 1997. 1523 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 1524 2001. 1526 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L. and M. 1527 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 1528 3948, January 2005. 1530 [RFC822] Crocker, D., "Standard for the format of ARPA Internet 1531 text messages", RFC 822, August 1982. 1533 [ReAuth] Nir, Y., "Repeated Authentication in IKEv2", 1534 draft-nir-ikev2-auth-lt-01 (work in progress), November 1535 2004. 1537 [SCVP] Freeman, T., Housley, R. and A. Malpani, "Simple 1538 Certificate Validation Protocol (SCVP)", 1539 draft-ietf-pkix-scvp-16 (work in progress), October 2004. 1541 Authors' Addresses 1543 Pasi Eronen 1544 Nokia Research Center 1545 P.O. Box 407 1546 FIN-00045 Nokia Group 1547 Finland 1549 EMail: pasi.eronen@nokia.com 1551 Paul Hoffman 1552 VPN Consortium 1553 127 Segre Place 1554 Santa Cruz, CA 95060 1555 USA 1557 EMail: paul.hoffman@vpnc.org 1559 Intellectual Property Statement 1561 The IETF takes no position regarding the validity or scope of any 1562 Intellectual Property Rights or other rights that might be claimed to 1563 pertain to the implementation or use of the technology described in 1564 this document or the extent to which any license under such rights 1565 might or might not be available; nor does it represent that it has 1566 made any independent effort to identify any such rights. Information 1567 on the procedures with respect to rights in RFC documents can be 1568 found in BCP 78 and BCP 79. 1570 Copies of IPR disclosures made to the IETF Secretariat and any 1571 assurances of licenses to be made available, or the result of an 1572 attempt made to obtain a general license or permission for the use of 1573 such proprietary rights by implementers or users of this 1574 specification can be obtained from the IETF on-line IPR repository at 1575 http://www.ietf.org/ipr. 1577 The IETF invites any interested party to bring to its attention any 1578 copyrights, patents or patent applications, or other proprietary 1579 rights that may cover technology that may be required to implement 1580 this standard. Please address the information to the IETF at 1581 ietf-ipr@ietf.org. 1583 Disclaimer of Validity 1585 This document and the information contained herein are provided on an 1586 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1587 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1588 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1589 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1590 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1591 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1593 Copyright Statement 1595 Copyright (C) The Internet Society (2005). This document is subject 1596 to the rights, licenses and restrictions contained in BCP 78, and 1597 except as set forth therein, the authors retain all their rights. 1599 Acknowledgment 1601 Funding for the RFC Editor function is currently provided by the 1602 Internet Society.