idnits 2.17.1 draft-harkins-ikev3-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 12, 2013) is 4031 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEV2IANA' -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEV3IANA' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) ** Downref: Normative reference to an Informational RFC: RFC 5297 ** Downref: Normative reference to an Informational RFC: RFC 6090 -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4718 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Harkins, Ed. 3 Internet-Draft Aruba Networks 4 Intended status: Standards Track April 12, 2013 5 Expires: October 14, 2013 7 The (Real) Internet Key Exchange 8 draft-harkins-ikev3-01 10 Abstract 12 The current version (v2) of the Internet Key Exchange failed to 13 address many of the shortcomings of the original version (v1). This 14 memo defines a new version (v3) of the Internet Key Exchange that 15 attempts to do so. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on October 14, 2013. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 53 2. Characteristics of Version 3 of IKE . . . . . . . . . . . . . 4 54 3. Differences from Previous Versions of IKE . . . . . . . . . . 4 55 3.1. Identity Confidentiality . . . . . . . . . . . . . . . . . 5 56 3.2. Single IKE SA, No Lifetime . . . . . . . . . . . . . . . . 5 57 3.3. Not A Request/Response Exchange . . . . . . . . . . . . . 5 58 3.4. State Machine Definition . . . . . . . . . . . . . . . . . 6 59 4. Cryptographic Tools . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. Authenticated Encryption . . . . . . . . . . . . . . . . . 6 61 4.2. Hash Function . . . . . . . . . . . . . . . . . . . . . . 7 62 4.3. Discrete Logarithm Cryptography . . . . . . . . . . . . . 7 63 4.4. Key Deriviation Function . . . . . . . . . . . . . . . . . 8 64 5. Authentication and Key Establishment . . . . . . . . . . . . . 9 65 5.1. Public Key Authentication . . . . . . . . . . . . . . . . 9 66 5.1.1. KE Payload with Public Key Authentication . . . . . . 9 67 5.1.2. AU Payload with Public Key Authentication . . . . . . 10 68 5.2. PSK Authentication . . . . . . . . . . . . . . . . . . . . 10 69 5.2.1. Hunting and Pecking with ECP Groups . . . . . . . . . 11 70 5.2.2. Hunting and Pecking with MODP Groups . . . . . . . . . 12 71 5.2.3. KE Payload with PSK Authentication . . . . . . . . . . 13 72 5.2.4. AU Payload with PSK Authentication . . . . . . . . . . 14 73 5.3. Deriving Shared Secrets . . . . . . . . . . . . . . . . . 15 74 6. The Internet Key Exchange Protocol . . . . . . . . . . . . . . 15 75 6.1. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 16 76 6.1.1. Init Messages . . . . . . . . . . . . . . . . . . . . 16 77 6.1.1.1. Construction of Init Messages . . . . . . . . . . 16 78 6.1.1.2. Processing of Init Messages . . . . . . . . . . . 17 79 6.1.2. Auth Messages . . . . . . . . . . . . . . . . . . . . 18 80 6.1.2.1. Construction of Auth Messages . . . . . . . . . . 18 81 6.1.2.2. Processing of Auth Messages . . . . . . . . . . . 19 82 6.2. IPsec Security Associations . . . . . . . . . . . . . . . 21 83 6.3. State Machine . . . . . . . . . . . . . . . . . . . . . . 21 84 6.3.1. Parent Process . . . . . . . . . . . . . . . . . . . . 22 85 6.3.2. Components of State Machine . . . . . . . . . . . . . 23 86 6.3.3. States . . . . . . . . . . . . . . . . . . . . . . . . 24 87 6.3.3.1. Nothing State . . . . . . . . . . . . . . . . . . 24 88 6.3.3.2. Initiation State . . . . . . . . . . . . . . . . . 25 89 6.3.3.3. Reception State . . . . . . . . . . . . . . . . . 26 90 6.3.3.4. Done State . . . . . . . . . . . . . . . . . . . . 27 91 6.3.4. Cleaning Up Protocol Instances . . . . . . . . . . . . 28 92 6.4. IKEv3 Payload Formats . . . . . . . . . . . . . . . . . . 28 93 6.4.1. IKE header . . . . . . . . . . . . . . . . . . . . . . 28 94 6.4.2. Generic IKE payload header . . . . . . . . . . . . . . 30 95 6.4.3. IKE Attributes payload . . . . . . . . . . . . . . . . 31 96 6.4.4. Identity Payload . . . . . . . . . . . . . . . . . . . 33 97 6.4.5. Nonce Payload . . . . . . . . . . . . . . . . . . . . 34 98 6.4.6. Key Exchange Payload . . . . . . . . . . . . . . . . . 34 99 6.4.7. Certificate Payload . . . . . . . . . . . . . . . . . 35 100 6.4.8. Certificate Request Payload . . . . . . . . . . . . . 36 101 6.4.9. Authentication Payload . . . . . . . . . . . . . . . . 36 102 6.4.10. Address Indication Payload . . . . . . . . . . . . . . 37 103 6.4.11. Traffic Selecor Payload . . . . . . . . . . . . . . . 37 104 6.4.12. Security Association Payload . . . . . . . . . . . . . 39 105 6.4.13. Vendor Indication Payload . . . . . . . . . . . . . . 40 106 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 107 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 108 9. Security Considerations . . . . . . . . . . . . . . . . . . . 41 109 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 110 10.1. Normative References . . . . . . . . . . . . . . . . . . . 41 111 10.2. Informative References . . . . . . . . . . . . . . . . . . 42 112 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43 114 1. Introduction 116 The Internet Key Exchange was first defined in [RFC2409] to generate 117 security associations for the IPsec protocols. That specification 118 was poorly written and suffered from too many options, many of which 119 were unneeeded and went unused. In short, it was confusing and 120 complicated. An effort was made to come up with a simpler and less 121 confusing version, and that resulted in [RFC4306], so-called IKEv2 122 ([RFC2409] was then dubbed IKEv1). While it was arguably simpler and 123 less confusing, IKEv2 failed to achieve its goal. It went through an 124 extensive clarification process that produced [RFC4718] and 125 development of a replacement specification for IKEv2, in [RFC5996]. 126 While [RFC5996] is definitely a cleaner protocol than [RFC2409] it 127 still has too many options and is too complicated, and confusing. 129 This memo defines an IKEv3 in an effort to have a simpler, more easy 130 to implement protocol, that that has a high probability of achieving 131 interoperability while retaining security and utility. 133 1.1. Requirements Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 2. Characteristics of Version 3 of IKE 141 Version 3 of the Internet Key Exchange is a simple peer-to-peer 142 protocol in which each side sends and receives two messages. It 143 performs mutual authentication, derives a shared, secret and 144 authenticated key, and negotiates parameters for IPsec security 145 associations (SAs) to protect transient data between the peers. 147 Either side can initiate the exchange to the other and both sides can 148 initiate simultaneously (hence the claim of a true "peer-to-peer" 149 exchange). This is advantageous for certain smart devices-- aka "the 150 Internet of things"-- or sensor network deployments where there is no 151 strict roles of client or server, initiator or responder. 153 In an effort to keep the definition of the Internet Key Exchange as 154 simple as possible, negotiation of the terms of its operation-- e.g. 155 encryption algorithm, hash algorithm-- is kept to a minimum. 157 3. Differences from Previous Versions of IKE 158 3.1. Identity Confidentiality 160 IKEv3 does not provide identity confidentiality. This is a tradeoff 161 made to increase simplicity in specification and, more importantly, 162 implementation at the cost of a feature whose benefit is somewhat 163 dubious. 165 While security on the Internet is a large issue (one that IKEv3 166 addresses) the problems associated with exposure of the identities of 167 two peers that are engaging in secure communication is not. 169 If identity hiding critical for a particular deployment, IKEv3 170 supports obfuscation of identity using an ID blob which has meaning 171 to the two peers of the exchange but has no meaning to any third 172 party that may observe it. 174 3.2. Single IKE SA, No Lifetime 176 IKEv3 can handle the situation where both sides initiate to each 177 other without resorting to carrying on two conversations and ending 178 up with two IKE Security Associations. 180 The IKEv3 SA is also short-lived. Its purpose is to create SAs for 181 IPsec and once it has done that the state that governed a particular 182 protocol run can go away. There is no notion of a long-lived IKE SA. 184 There is no SA lifetime necessary for IKEv3 to negotiate. This also 185 has the benefit of doing away with the Delete payloads and their 186 corresponding complexity as well as the complexity associated with 187 rekeying of SAs. 189 There is no need for "initial contact" notification or the need to 190 negotiate, or rekey, multiple IKE SAs. 192 3.3. Not A Request/Response Exchange 194 [RFC2409] and [RFC5996] are both Request/Response protocols. There 195 are defined roles-- one side is an "Initiator" and the other is a 196 "Responder"-- and one side makes Requests and the other Responds to 197 those requests. 199 In IKEv3 there are no roles involved-- no clients and servers, no 200 Initiators and Responders-- just two peers who perform identical 201 behavior. Since either side can initiate and both sides can initiate 202 simultaneously, there is no need to deal with "Exchange Collisions". 203 All the protocol specification complexity to address the problems 204 that occur due to role-based protocol definition goes away. 206 Many of the IKEv1 and IKEv2 use cases involved strict roles and IKEv3 207 can support them because the state machine (see Section 6.3) can 208 handle the case where one side initiates and the other responds just 209 as easily as it can handle the case where both sides initiate 210 simulteneously. 212 3.4. State Machine Definition 214 IKEv3 defines a very simple state machine that each side runs through 215 to implement the protocol. Accurate compliance with the state 216 machine ensures interoperability. 218 The state machine allows the protocol definition to be entirely from 219 the point of view of the implementation, making protocol 220 implementation much easier. The protocol is defined in terms of 221 actions causing events which result in a deterministic advancement of 222 state until the protocol is finished. The state machine definition 223 assures that each side either completes the protocol or neither side 224 completes the protocol. 226 Previous versions of IKE lacked a state machine definition and it 227 showed. IKEv1 achieved interoperability through implementor "bake- 228 offs" and not through a coherent specification. IKEv2 has gone 229 through forty (40) revisions, in total, in an effort to clarify and 230 straighten out ambiguous and confusing text and remains to this day a 231 complicated, ambiguous and confusing specification. 233 4. Cryptographic Tools 235 IKEv3 makes use of certain cryptographic primitives to achieve its 236 goals of key generation, mutual authentication, and security. Each 237 of the following subsections indicate negotiable components of the 238 IKE Security Association that are used during the protocol run. 239 Different protocol runs can negotiate different components and the 240 components to use in a particular run of the protocol are established 241 by exchanging payloads in the Init message that describe the 242 attributes of the IKE Security Association (see Section 6.4). 244 4.1. Authenticated Encryption 246 Authenticated encryption is employed by IKEv3 to protect the payloads 247 that set up IPsec Security Associations as well as any vendor- 248 specific payloads that are added to the final two messages of the 249 protocol. It is therefore a negotiable component. The privacy 250 algorithm negotiated MUST be a cipher mode, or construction of cipher 251 mode plus integrity check, that provides authenticated encrytion. 253 AES in SIV mode as defined in [RFC5297] is used in IKEv3 to 254 accomplish this goal. SIV supports authenticated encryption with 255 associated data (which is authenticated but not encrypted) and does 256 not require complex managment of a unique counter space to ensure 257 security. It is simple, secure and robust. A perfect fit for IKEv3. 259 4.2. Hash Function 261 A hash function takes a arbitrary-sized input and deterministically 262 produces a fixed sized output, called a digest. It is also a one-way 263 function: it is very easy to produce a digest but computationally 264 infeasible to reconstruct the arbitrary-sized input given a 265 particular digest. 267 IKEv3 uses a hash function, in [RFC2104] mode for key derivation and 268 key confirmation. IKEv3 also uses a hash function to construct a 269 random function, H(): 271 H(x) = HMAC-Hash(0^n, x) 273 where Hash is the agreed-upon hash function and "0^n" signifies a key 274 of all zeros whose length equals the digest size of the hash 275 function. 277 IKEv3 defines SHA-256 and SHA-512 (as defined in [RFC4634]) for use 278 as hash functions. 280 4.3. Discrete Logarithm Cryptography 282 The Internet Key Exchange uses discrete logarithm cryptography. Each 283 party to the protocol derives ephemeral public and private key pairs 284 with respect to a particular domain parameter set, called a "group". 285 The group can be based on either finite field cryptography (modular 286 exponentiation, or MODP, groups) or elliptic curve cryptography (ECP 287 groups). 289 In this memo, elements in a group are denoted in upper case and 290 scalar values are in lower case-- element X and scalar x. 292 Groups are identified in messages using a convenient registry 293 maintained by IANA (see Section 8). Each group's domain parmameter 294 set contains the following: 296 o p - a prime number defining a finite field 298 o G - a generator, a base element forming a group 299 o q - a prime number indicating the order of the group defined by G 301 ECP groups additionally define "a" and "b" which are components of 302 the equation of the elliptic curve-- y^2 = x^3 + ax + b. Some MODP 303 groups are based on safe primes and do not have a specific order 304 defined. For these groups only, the order, q, SHALL be (p-1)/2. 306 For each group, the following operations are defined: 308 o "scalar operation" -- takes a scalar and an element in the group 309 to produce another element in the group-- Z = scalar-op(x, Y). 310 For ECP groups this is multiplication of the element by the 311 scalar; for MODP groups this is exponentiation of the element to 312 the scalar. 314 o "element operation" -- takes two elements in the group to produce 315 a third element in the group-- Z = element-op(X, Y). For ECP 316 groups this is point addition; for MODP groups this is modular 317 multiplication. 319 o "inverse operation" -- takes an element in the group and returns 320 another element in the group such that the element operation on 321 the two produces the identity element of the group-- Y = 322 inverse(X). 324 ECP: element-op(Y, inverse(Y)) = "point at infinity" 326 MODP: element-op(Y, inverse(Y)) = 1 328 In addition, ECP groups require a mapping function, r = F(R), to 329 convert a group element to an integer. The mapping function used in 330 this memo returns the x-coordinate of the point it is passed. MODP 331 groups do not need a mapping function as group elements in MODP 332 groups can be directly represented as integers. For the purpose of 333 protocol definition, the function F() when used with MODP groups will 334 be the identity function-- i.e. i = F(i). 336 4.4. Key Deriviation Function 338 IKEv3 uses a key derivation function, KDF(), to stretch a random key 339 to an indeterminate length and bind some arbitrary data to the 340 stretched key. 342 For ease of programming, IKEv3 uses the prf+() function from 343 [RFC5996] which, in turn, was derived from the prf() function in 344 [RFC2409], as its KDF(). 346 THe pseudo-random function at the core of the prf+() construct is the 347 agreed-upon hash function in HMAC ([RFC2104]) mode. When KDF() is 348 called for in this memo, it is prf+() from [RFC5996] using HMAC-Hash 349 where hash is the agreed-upon hash algorithm. 351 5. Authentication and Key Establishment 353 The goal of any pairwise authenticated key exchange is key 354 establishment and mutual authentication. The IKEv3 protocol achieves 355 these goals. The particular method of key establishment is tied to 356 the authentication method which is tied to the type of credential 357 used for authentication-- a (certified) public key or a PSK. 359 5.1. Public Key Authentication 361 Public key authentication uses a Diffie-Hellman key exchange for key 362 establishment and digital signatures by a private key whose public 363 analog is trusted by the peer. 365 5.1.1. KE Payload with Public Key Authentication 367 The KE payload is used to present a Diffie-Hellman public value to 368 the peer. Each peer generates a random number between one (1) and 369 the order of the group, q, exclusive. This represents the peer's 370 private value, priv. The peer then performs the group's scalar 371 operation (see Section 4.3) with the group's generator to produce the 372 public value, Pub: 374 Pub = scalar-op(priv, G) 376 The public value is encoded in to the body of the KE Payload (see 377 Section 6.4) according to the integer to octet string conversion 378 technique from [RFC6090]. 380 The Diffie-Hellman key exchange is completed when both sides have 381 finished sending and receiving an Init message. Each side generates 382 the same shared secret, secret, by applying the mapping function, F() 383 (see Section 4.3), to the result of the group's scalar operation with 384 the entities private value, priv, and the peer's public key, PubPeer: 386 secret = F(scalar-op(priv, PubPeer)) 388 The secret is then used to generate three additional keys, the 389 authenticated encryption key, the confirmation key, and a key- 390 derivation key. (see Section 5.3). 392 5.1.2. AU Payload with Public Key Authentication 394 The AU payload contains a digital signature of the confirmation key 395 and both peers' Init messages concatenated together, transmitter's 396 Init message first. For example, assuming Alice sent the message 397 InitA and Bob send the message InitB, Alice's digital signature would 398 be "sig" where: 400 sig = Sign-Alice(cKEY | InitA | InitB) 402 where "|" signifies concatenation, and Sign-Alice() indicates a 403 digital signature of that data passed to it using the public key of 404 Alice. The portions of the Init messages that are covered by the 405 digital signature consist of the IKE header (inclusive) to the end of 406 the payload. 408 Bob would similarly send: 410 sig = Sign-Bob(cKEY | InitB | InitA) 412 since Bob was the transmitter of InitB. 414 To maintain a consistent level of security for IKEv3, the hash 415 algorithm used to generate the digital signature SHALL be the one 416 negotiated in the IKE Security Association that is used for other 417 hashing purposes in IKEv3. The body of the AU payload (see 418 Section 6.4) SHALL consist of the digital signature as a bitstring. 420 5.2. PSK Authentication 422 PSK authentication uses the "dragonfly" key exchange to both generate 423 a shared, and secret, key and to mutually authenticate the peers to 424 each other. Each side proves knowledge of the PSK in a manner that 425 is resistant to dictionary attack. 427 Each side proves possession of a single PSK (or password), there is 428 no notion of a "client's password" and a "server's password"; there 429 is just the one. This single PSK MUST be provisioned on the two 430 peers prior to beginning the IKEv3 exchange. Since there is only one 431 PSK it SHOULD have only one name, which is provisioned along with the 432 PSK. It is this name that is used in the ID payload when initiating 433 the dragonfly exchange to the peer. Note: it may make sense in 434 certain client/server deployments to have a proper client username 435 assigned to the password, in which case the server proving possession 436 of the client's password-- identified by username-- authenticates it 437 to the client. 439 When PSK authentication is chosen for a particular run of the 440 protocol, the KE payload contains each peer's "commit" contribution 441 to the dragonfly exchange and the AU payload contains a keyed message 442 authentication code binding the secret key to both peers' Init 443 messages concatenated together. 445 Prior to beginning the "dragonfly" exchange, both peers MUST agree 446 upon a secret element in the chosen group. A secret seed is 447 generated and that see is used in a group-specific hunting-and- 448 pecking process-- one process for MODP groups and another for ECP 449 groups. First, an 8-bit counter is set to one (1) and a secret base 450 is computed using the negotiated one-way function with the secret 451 PSK, and the counter: 453 base = H(PSK | counter) 455 The base is then stretched using the key derivation function from 456 Section 4.4 to the length of the prime from the group's domain 457 parameter set: 459 seed = KDF(base, "IKE PSK Hunting and Pecking") 461 The seed is then passed to the group-specific hunting and pecking 462 technique. 464 5.2.1. Hunting and Pecking with ECP Groups 466 The ECP specific hunting and pecking technique entails looping until 467 a valid point on the elliptic curve has been found. The seed is used 468 as the x-coordinate with the equation of the curve to solve for a 469 y-coordinate. If there is no solution, the counter is incremented, a 470 new base and new seed are generated and the hunting and pecking 471 continues. If there is a solution an ambiguity exists because two 472 values for the y-coordinate would be valid. The low-order bit of the 473 base is used to unambiguously determine the y-coordinate and the 474 resulting (x,y) pair becomes the secret generator for the dragonfly 475 exchange, SKE. 477 Algorithmically, the process looks like this: 479 found = 0 480 counter = 1 481 do { 482 base = H(psk | counter) 483 seed = KDF(seed, "IKE PSK Hunting And Pecking") 484 if (seed < p) 485 then 486 x = seed 487 if ( (x^3 + ax + b) is a quadratic residue mod p) 488 then 489 y = sqrt(x^3 + ax + b) 490 if (LSB(y) == LSB(base)) 491 then 492 SKE = (x,y) 493 else 494 SKE = (x, p-y) 495 fi 496 found = 1 497 fi 498 fi 499 counter = counter + 1 500 } while (found == 0) 502 Figure 1: Fixing SKE for ECP Groups 504 5.2.2. Hunting and Pecking with MODP Groups 506 The MODP specific hunting and pecking technique entails finding a 507 random element which, when used as a generator, will create a group 508 with the same order as the group created by the generator from the 509 domain parameter set. The secret generator is found by 510 exponentiating the seed to the value ((p-1)/q), where p is the prime 511 and q is the order from the domain parameter set. If that value is 512 greater than one (1) it becomes SKE, otherwise the counter is 513 incremented, a new base and seed are generated, and the hunting and 514 pecking continues. 516 Algorithmically, the process looks like this: 518 found = 0 519 counter = 1 520 do { 521 base = H(psk | counter) 522 seed = KDF(base, "IKE SKE Hunting And Pecking") 523 if (seed < p) 524 then 525 SKE = seed ^ ((p-1)/r) mod p 526 if (SKE > 1) 527 then 528 found = 1 529 fi 530 fi 531 counter = counter + 1 532 } while (found == 0) 534 Figure 2: Fixing SKE for MODP Groups 536 5.2.3. KE Payload with PSK Authentication 538 Once SKE has been determined, the peer randomly chooses two numbers 539 between one and the order of the group, q, exclusively. These 540 represent a private value and a mask. The peer then generates a 541 scalar and an element using private, mask, and SKE: 543 scalar = (private + mask) mod q 545 Element = inverse(scalar-op(mask, SKE)) 547 The scalar and element, respectively, are encoded into the KE payload 548 by using the integer to octet string conversion technique from 549 [RFC6090]. Octet strings are pre-pended with zero (0), if necessary, 550 to achieve the required resulting length. Since the length of each 551 component of the KE payload is implicitly known, the scalar and 552 element can be extracted from the KE payload for processing. 554 The scalar is the same length as the order of the group. It is 555 converted into an octet string and then the octet string is inserted 556 into the body of the KE Payload. 558 If the selected group is MODP, the element can be treated directly as 559 an integer and converted into an octet string. Its length is the 560 same as the length of the prime of the group. The converted octet 561 string is appended to the octet string representation of the scalar. 563 If the selected group is ECP, the element is an (x,y) pair and each 564 coordinate is separately converted into an octet string, each of 565 which is the same length as the prime of the group. The octet string 566 representation of the x-coordinate SHALL be appended to the scalar 567 and the y-coordinate SHALL be appended to the x-coordinate. 569 The dragonfly key handshake is completed when both sides have 570 finished sending and receiving an Init message. Each side generates 571 the same shared secret, secret, by performing the following 572 computation: 574 secret = F(scalar-op(private, 575 element-op(PeerElement, 576 scalar-op(peerscalar, SKE)))) 578 where peerscalar and PeerElement are scalar and element from the 579 peer's KE payload taken out of a received Init message. The secret 580 is then used to generate three additional keys, the authenticated 581 encryption key, the confirmation key, and a key-derivation key. (see 582 Section 5.3). 584 5.2.4. AU Payload with PSK Authentication 586 The AU payload contains a keyed message authentication code which 587 proves knowledge of the derived secret, and therefore knowledge of 588 the PSK, and binds the two Init messages to the authenticated state. 590 Each side produces an authenticating message authentication code, 591 mac, by invoking the HMAC version of the negotiated hash function and 592 passing the confirmation key, cKEY, as the key and the concatentation 593 of both peers' Init messages concatenated together, transmitter's 594 Init message first. For example, assuming Alice sent the message 595 InitA and Bob sent the message InitB, Alice's message authentication 596 code would be "mac" where: 598 mac = HMAC-Hash(cKEY, InitA | InitB) 600 where "|" signifies concatentation and HMAC-Hash is the [RFC2104] 601 instantiation of the negotiated hash algorithm, Hash. The portions 602 of the Init messages passed HMAC-Hash consist of the IKE header 603 (inclusive) to the end of the payload. 605 Bob would similarly send: 607 mac = HMAC-Hash(cKEY, InitB | InitA) 609 since Bob was the transmitter of InitB. 611 5.3. Deriving Shared Secrets 613 Upon successful completion of key establishment, IKEv3 produces three 614 keys, an authenticated encryption key, aeKEY, to protect the Auth 615 Messages, a confirmation key, cKEY, and a derivation key, dKEY, used 616 to derive (a) shared secret(s) when constructing IPsec Security 617 Associations (see Section 6.2). 619 The length of aeKEY depends on the authenticated encryption mode used 620 and the length of cKEY and dKEY SHALL be the length of the digest of 621 negotiated hash function. The keys are derived by passing the two 622 nonces, appended to each other with the lexicographically larger 623 nonce being first, as the key and secret from the authenticated key 624 exchange concatenated with the label "IKEv3 Key Derivation" as the 625 data: 627 aeKEY | cKEY | dKEY = KDF(max(Na, Nb) | min(Na, Nb), 628 secret | "IKEv3 Key Derivation") 630 where Na and Nb are the two nonces from the exchange (the transmitter 631 is irrelevant in this peer-to-peer protocol), max() returns the 632 lexicographically larger of the two parameters passed, and min() 633 returns the lexicographically smaller of the two parameters passed. 635 The key aeKEY SHALL be used to protect the exchange of Auth Messages, 636 the same key is used in both directions. 638 6. The Internet Key Exchange Protocol 640 The Internet Key Exchange (IKE) authenticates two peers to each other 641 and derives security associations for use by IPsec. The credentials 642 supported by IKE are PSKs and certificates. 644 IKE supports varying degrees of security by supporting various domain 645 parameter groups, encryption algorithms, and hash algorithms. 647 IKEv3 supports detection of NATs between two peers through the 648 exchange of source and destination indicators. When (a) NAT(s) is 649 (are) present between the peers the source and/or destination 650 addresses and/or ports will be modified and differ from those in the 651 indicators. When (a) NATS(s) is (are) detected, UDP encapsulation of 652 ESP traffic as defined by [RFC3948] is required. Note that IKEv3 is 653 not required to use port 4500 in the presense of (a) NAT(s). 655 6.1. Message Flow 657 In the IKEv3 protocol each peer sends and receives an Init message 658 and an Auth message. The Init message negotiates the type of 659 authentication to be used between the peers, identifies the peers to 660 each other, exchanges random nonces, and exchanges the components of 661 a cryptographic key exchange. The Auth message authenticates the 662 peer to the other peer and establishes IPsec security associations. 664 Messages are comprised of an IKE header followed by one or more 665 payloads. The on-the-wire format of the IKE header and all payloads 666 defined for use in IKE are in Section 6.4. 668 As is typical in these sorts of memos, the participants in the 669 protocol are Alice and Bob. The exchange of Init and Auth messages 670 between Alice and Bob look like this: 672 Alice Bob 673 ------ ---- 674 Init: hdr, IAa, IDa, NOa, hdr, IAb, IDb, NOb, 675 KEa [, CRa] ----> <----- KEb [, CRb ] 676 Auth: hdr, { [CEa, ] AUa, AIs, hdr, { [CEb, ] Aub, AIs, 677 AId, SAa, TSs, TSd } ----> <----- AId, SAb, TSs, TSd } 679 Where { x } indicates the authenticated encryption of payload x using 680 the mode agreed upon in the exchange of IA payloads. 682 6.1.1. Init Messages 684 6.1.1.1. Construction of Init Messages 686 The IKEv3 header contains two message identifiers called SPIs, one 687 chosen by the transmitter of the message and one chosen by the 688 (intended) recipient of the message. The local SPI from the IKE 689 security association is copied into the transmitter SPI field. If a 690 peer SPI exists in the IKE security association, it is copied into 691 the receipient SPI field. If there is no peer SPI in the IKE 692 security association, the receipient SPI field remains all zero. 694 The first payload in an Init message MUST be an IA payload which 695 indicates the terms by which the IKE protocol will be run (see 696 Section 4). If this Init message is being constructed in response to 697 receipt of an accepted Init message then the attributes from the 698 received, and accepted, Init message MUST be copied into the Init 699 message being constructed. If the Init message is being constructed 700 due to an indication to the IKEv3 protocol to establish IPsec SAs 701 with a remote peer (see Section 6.3) then the attributes MUST reflect 702 the policy that accompanied that indication. 704 The next payload after the IA payload MUST be the ID payload which 705 indicates the identity of the peer sending the Init message (see 706 Section 3.1 for a discussion on identity confidentiality). The next 707 payload MUST be a NO payload which contributes additional randomness 708 to the exchange. The next payload MUST be a KE payload. The 709 particular construction of the body of the KE payload depends on the 710 authentication method being used for this run of the protocol (see 711 Section 5). Finally, a CR payload MAY be added if the authentication 712 method is public key authentication and the sender of the Init 713 message believes that it needs the peer's public key. 715 Vendor specific payloads MAY be appended to an Init message to convey 716 some additional semantics governing the Init message. 718 6.1.1.2. Processing of Init Messages 720 The first step of processing an Init Message is to record the peer's 721 SPI by taking it out of the transmitter SPI field of the IKEv3 header 722 and storing it in the IKE security association as the peer's SPI. 724 Next, the attributes that govern the IKEv3 protocol are checked. If 725 the recipient SPI field is not all zeros (0) then the attributes in 726 the received Init message MUST be identical to the attributes that 727 have already been sent to the peer. If they are not, processing 728 indicates a failure and stops. If the recipient SPI field is all 729 zeros (0) and a message has not been sent to the peer then the 730 attributes are checked for acceptability. If they are not acceptable 731 processing SHALL indicate a failure and stop. If they are 732 acceptable, then processing continues. Otherwise, if the recipient 733 SPI field is all zeros (0) and a message has already been sent to the 734 peer then there are three possible cases: 736 1. The attributes are identical to the attributes sent to the peer, 737 so processing continues. 739 2. The attributes are not acceptable in which case the message is 740 discarded and processing stops. 742 3. The attributes are acceptable but differ from those sent. In 743 this case, a test is made to see which side drops its offer. 744 Each side has sent its SPI to the other as the transmitter SPI in 745 its Init message. If the low-order bit of those SPIs are 746 identical then the transmitter of the larger SPI wins, if the 747 low-order bit of those SPIs differ then the transmitter of the 748 smaller SPI wins. The winner SHALL discard the message and the 749 loser SHALL indicate a failure. In both cases, processing stops. 750 Note: the loser will destroy all state associated with this 751 conversation and the winner will retransmit, allowing the two to 752 synch up on the new, mutually acceptable attributes. 754 Finally, the nonce and key exchange data are extracted from the 755 received Init message and processing finishes successfully. If the 756 peer requested a certificate, that fact is noted to ensure that a 757 certificate is included in the subsequent Auth message. 759 6.1.2. Auth Messages 761 6.1.2.1. Construction of Auth Messages 763 The Auth message MAY optionally contain a certificate payload (CE) 764 with the public key of the transmitter and MUST contain, in the 765 following order, an Auth payload (AU), a source Address Indication 766 payload (AIs), a destination Address Indication payload (AId), a 767 Security Association payload (SA), and two Traffic Selector payloads 768 (TS). Optional vendor specific payload(s) MAY be appended to the 769 message but MUST be the last payload(s) in the message. 771 The contents of AU payload are determined by the authentication 772 method agreed-upon during the exchange of Init messages (see 773 Section 5). The value of the Auth payload, from the point of view of 774 the transmitter, SHALL be determined and copied into the data portion 775 of the payload. 777 The AIs and AId payloads are constructed from the point of view of 778 the transmitting peer. The source Address Indication payload, AIs, 779 is the address and port being used as the source of the Auth message 780 and the destination Address Indication payload, AId, is the address 781 and port of the destination of the Auth message. The source Address 782 Indication payload MUST precede the destination Address Indication 783 payload. 785 The contents of the SA payload describe the transforms and options 786 that will be represented in the IPsec SA after successful 787 authentication. If this Auth message is being constructed in 788 response to the receipt of an Auth message from the peer, the 789 transforms in the Auth payload MUST be identical to those accepted 790 when processing the peer's Auth message. If a locally-unique SPI 791 with which to identify the security association for received IPsec 792 packets has not yet been chosen, the transmitter choses a SPI. 794 The TS payloads contains a description of the flows to protect using 795 IPsec. There are two (2) TS payloads in each Auth message. The 796 first describes the source of the flow and the second describes the 797 sink of the flow, both from the perspective of the transmitter of the 798 Auth message. If local Traffic Selector policy has been narrowed due 799 to the processing of the peer's Auth message, then the narrowed 800 policy SHALL be reflected in the TS payloads. 802 Auth messages are sent after each side has both sent and received an 803 Init message and completed the key establishment phase of the IKEv3 804 protocol. While the peers have not yet authenticated each other, 805 they share a secret which can be used to secure the Auth messages. 806 This is accomplished by using the authenticated encryption mode that 807 was agreed-upon during the exchange of Init messages. 809 All the payloads of the Auth message are encrypted-- that is, 810 everything after the IKEv3 header to the end of the message. The 811 IKEv3 header, and the encrypted payloads are all authenticated. 813 When [RFC5297] is used for authenticated encryption the IKEv3 header 814 from the transmitter's SPI (inclusive) to the Length (inclusive) is 815 passed as associated data, and the data immediately following the 816 IKEv3 header, from the generic IKEv3 header of the first payload 817 (inclusive) to the end of the message is the data to encrypt. The 818 ICV/SIV field of the IKEv3 header is not included in the associated 819 data passed to AES-SIV. 821 The output of the [RFC5297] mode is ciphertext and a Synthetic 822 Initialization Vector (SIV). The SIV SHALL be copied into the IKEv3 823 header and the ciphertext is appended to the IKEv3 header to form the 824 complete Auth message. 826 6.1.2.2. Processing of Auth Messages 828 Auth messages are encrypted and authenticated so the first step in 829 processing is to verify their integrity and to decrypt them. When 830 [RFC5297] is used, the Synthetic Initialization Vector (SIV) is 831 copied from the ICV/SIV field in the IKEv3 header. The IKEv3 header 832 from the transmitter's SPI (inclusive) to the length (inclusive) is 833 passed, along with the SIV to AES-SIV. If AES-SIV outputs FAIL the 834 message is discarded and processing stops. If AES-SIV outputs 835 plaintext, the plaintext will be the sequence of payloads that 836 comprise the Auth message. 838 The first payload will be the Auth payload (AU). The contents of the 839 AU payload are determined by the authentication method agreed-upon 840 during the exchange of Init messages (see Section 5). The value of 841 the the Auth message from the point of view of the transmitter (i.e. 842 the peer) is calculated and compared to the value in the data portion 843 of the AU payload. If they differ, the peer fails authentication, 844 processing stops and a failure MUST be returned. If they are 845 identical processing continues. 847 Next the Address Indication payloads are checked. If the source 848 address or port of the received message differ from the address or 849 port in the source Address Indication payload, or if the destination 850 address or port of the received message differ from the address or 851 port in the destination Address Indication payload then a NAT is 852 detected. Othewise, a NAT is not detected. 854 The SA payload is next. The transforms in the SA payload are checked 855 to determine whether they are acceptable according to local policy. 856 If they are not the message is discarded and processing stops. If 857 they are, then there are three possibilities: 859 o An Auth message has not yet been sent to the peer, in which case 860 processing continues; or, 862 o An Auth message has been sent to the peer and the transforms are 863 identical to those sent, in which case processing continues; or, 865 o An Auth message has been sent to the peer and the transforms 866 differ from those sent. In this case, a test is made to see 867 which side's offer prevails. Each side has sent its IPsec SPI to 868 the other in the SA payload. If the low-order bit of those SPIs 869 are identical then the transmitter of the larger SPI prevails. 870 If the low-order bit of those SPIs differ then the transmitter of 871 the smaller SPI prevails. The transforms offered by the 872 prevailing party SHALL be adopted by the party which does not 873 prevail. Processing continues. 875 The Traffic Selectors in the TS payloads are next checked to 876 determine whether they are accptable according to local policy. If 877 the they are not acceptable, and no narrowing of the scope of the 878 traffic flows is possible-- i.e. no intersection between the TS 879 payloads and local policy-- the Auth message SHALL be discarded, 880 processing stops. 882 If the Traffic Selectors are completely satisfactory and require no 883 narrowing, then the Traffic Selectors are retained for creation of 884 IPsec SAs and construction of an Auth message (if one has not already 885 been sent). 887 If the Traffic Selectors are partially acceptable, and require 888 narrowing, then the union of the local policy describing the flow and 889 the Traffic Selectors describing the flow SHALL be retained for 890 creation of IPsec SAs and construction of an Auth message (if one has 891 not yet already been sent). 893 If an Auth message has not yet been sent, a locally-unique SPI SHALL 894 be created to identify the IPsec SA for received IPsec-protected 895 packets. This SPI MUST be retained for use when constructing the 896 Auth message response. 898 Upon completion of processing an Auth message, Two IPsec SAs MUST be 899 instantiated (e.g. plumbed into the kernel) with the indicated 900 transforms for the flow described in the (possibly narrowed) Traffic 901 Selectors, one in each direction. The locally-unique SPI becomes the 902 identifier to look up the SA for inbound IPsec packets and the peer's 903 SPI (from its SA payload) becomes the identifier to look up the SA 904 for outbound IPsec packets. 906 If a NAT was detected, the IPsec SAs MUST use UDP encapsulation for 907 IPsec (see [RFC3948]). Since both sides know the original addresses 908 and ports and the NATted addresses and ports, it is possible to 909 obtain the required information to perform the necessary 910 decapsulation procedures on received UDP-encapsulated IPsec packets. 912 6.2. IPsec Security Associations 914 The goal of the Internet Key Exchange is the creation of Security 915 Associations (SAs) for [RFC4301]. SAs are established using Security 916 Association (Section 6.4.12) and Traffic Selector (Section 6.4.11) 917 payloads to negotiate the flow(s) to protect and the means to go 918 about protecting it (them). 920 IKEv3 derives keys for IPsec SAs using the KDF (Section 4.4). The 921 key derivation key, dKEY, established in Section 5.3 is used as the 922 key and the label "IPsec Key Derivation" is used as the data: 924 key = KDF(dKEY, "IPsec Key Derivation") 926 The length of the key derived by KDF depends on the parameters of the 927 IPsec SA and the key lengths used by the underlying primitives. If 928 multiple, distinct, keying material is used-- for example, an ESP SA 929 that performs encryption and integrity protection separately-- the 930 key used for encryption MUST be taken from first and the key used for 931 integrity protection MUST be taken from the remaining bits. 933 6.3. State Machine 935 The IKEv3 protocol is managed by a parent process that receives 936 protocol events and IKEv3 packets and passes them on to instances of 937 the IKEv3 state machine. 939 The state machine for IKE defines the behavior of a single run of the 940 protocol. Each peer maintains a "protocol instance" for each remote 941 peer that it is actively performing the protocol with that defines 942 the current state of the protocol for that peer. The state machine 943 guarantees that both sides will complete the protocol with each side 944 installing IPsec Security Associations or each side will fail to 945 complete the protocol. 947 The state machine addresses the potential of dropped messages with a 948 retransmission timer. This memo does not specify a period that state 949 machines use when setting its retransmission timer. 951 6.3.1. Parent Process 953 The parent process of the IKEv3 state machine handles events from the 954 IPsec SADB (e.g. an "acquire" message to create an IPsec security 955 association) as well as receives incoming IKEv3 messages that it 956 dispatches to state machine instances. 958 The parent process is also responsible for creation of state machine 959 processes. The state of a state machine is stored in an IKEv3 960 security association so creation of a state machine process entails 961 creation of a nascent IKEv3 security association, generating a unique 962 and unpredictable local SPI, setting the peer address, and putting 963 the state machine in NOTHING state. 965 When the parent process receives an event from the IPsec SADB to 966 create an IPsec security association it first checks whether there is 967 an existing IKEv3 state machine process with the indicated peer. If 968 so, the parent process drops the event and waits for the process to 969 complete. If there is no existing state machine process, the parent 970 process creates a new state machine (see above) and sends the newly 971 created state machine process a START event. 973 When the parent process receives an IKEv3 packet from a remote peer 974 it first checks the receipient SPI field in the received packet. 976 If the recipient SPI field is all zeros, it indicates a peer that is 977 initiating. If the IKEv3 message is an Auth frame, it SHALL be 978 dropped as being meaningless (it is not possible to initiate IKEv3 979 with an Auth message). If the IKEv3 message is an Init message, the 980 parent process checks whether there is an existing IKEv3 state 981 machine process for the remote peer (the transmitter of the packet) 982 that is in Initiation State. If so, the received message is passed 983 to the state machine process with an INIT event. Otherwise, if there 984 is no existing IKEv3 state machine process in Initiation State, the 985 parent process creates an IKEv3 state machine process (see above) and 986 passes the received message and an INIT event to it. 988 If the receipient SPI field is not all zeros, the parent process uses 989 the recipient SPI to look up an existing IKEv3 process. If none 990 exists, the packet SHALL be dropped. If the parent process succeeds 991 in looking up an existing IKEv3 state machine process using the 992 recipient SPI, the message is passed to that state machine process 993 with the appropriate event-- an INIT event for an Init message and an 994 AUTH event for an Auth message. 996 6.3.2. Components of State Machine 998 The following states are part of the state machine: 1000 - Nothing: a quiescent state in which nothing has happened 1002 - Initiation: an Initiator has sent an Initiate message to a peer 1004 - Reception: a Responder has sent an Initiate message to a peer 1006 - Done: an Authenticate message has been sent to a peer 1008 The following variables are used in the state machine: 1010 - retrans: the number of retransmissions made (unsigned) 1012 - thresh: the maximum nuber of retransmissions allowed (unsigned) 1014 - committed: a counter on transmitted Auth messages (signed) 1016 - reauth: a counter on received Auth messages (signed) 1018 The following events are delivered to the state machine: 1020 - START: an instruction to initiate IKE to a peer 1022 - INIT: receipt of an Initiate message from a peer 1024 - AUTH: receipt of an Authenticate message from a peer 1026 - TM: expiry of the retransmission timer 1028 The following actions are taken by the state machine: 1030 - init: send an Initiate message to a peer 1032 - auth: send an Authenticate message to a peer 1034 The following timers are used by the state machine: 1036 - tm: the retransmission timer 1038 - fin: a deletion timer 1040 6.3.3. States 1042 The state machine for an IKEv3 process is show in Figure 3. 1044 ----------- 1045 | Nothing | 1046 ----------- 1047 / \ 1048 START/init / \ INIT/init 1049 / \ 1050 / \ 1051 ___ / \ ___ 1052 / \ V V / \ INIT/init 1053 TM/init | \ ------------ ------------ / | TM/init 1054 \ ----->| Initiation | | Reception | <----/ 1055 ------------ ------------ 1056 | | 1057 | INIT/auth* | 1058 | TM/auth | 1059 INIT/auth | ___ | AUTH/auth 1060 \ / \ / 1061 \ / \ / 1062 \ | | / ____ 1063 V \ V V / \ 1064 -------------- / | AUTH/auth* 1065 | Done | <------/ 1066 -------------- 1068 Figure 3: Protocol State Machine 1070 6.3.3.1. Nothing State 1072 Nothing state is the state in which an instance of the IKE state 1073 machine has just been created and has not received any events or 1074 performed any actions yet. Two events cause the state machine to 1075 exit Nothing state: a START event, and an INIT event. 1077 When a state machine instance in Nothing state receives a START event 1078 the IKE peer initiates a connection to another peer. The information 1079 the IKE peer obtains as part of the START event is implementation 1080 specific but MUST idicate at a minimum the following: 1082 o IP address of peer 1084 o SPD information regarding the type of IPsec security association 1085 to form. 1087 The method in which policy information regarding the type of 1088 authentication to propose, what group to use, etc., is out of scope 1089 of this memo. This information MUST be obtained but whether it is 1090 part of the START event indication or obtained as part of separate 1091 IKE configuration is irrelevant to the protocol. 1093 The peer derives a session identifier, or SPI, to use as its 1094 transmitting SPI. 1096 The peer retains the SPD information and SPI and constructs an Init 1097 message according Section 6.1.1.1 and transmits the message to the IP 1098 address of the peer. The state machine assigns the value zero (0) to 1099 the retrans counter, to the committed counter, and to the reauth 1100 counter. It sets the restransmission timer, and transitions to state 1101 Initiation. 1103 When a state machine instance in Nothing state receives an INIT 1104 event, it signifies the reception of an Init message from a remote 1105 peer. The instance retains the IP address of the peer, extracts the 1106 transmitter's SPI from the message, and assigns the value zero (0) to 1107 the retrans counter, the committed counter and the reauth counter. 1108 It then processes the Init message according to Section 6.1.1.2. If 1109 processing of the Init message is successful, the instance generates 1110 an Init message for the peer according to Section 6.1.1.1, transmits 1111 the message to the peer, sets the retransmission timer and 1112 transitions to state Reception. If processing of the Init message is 1113 unsuccessful, the protocol instance remains in Nothing state and all 1114 state created as a result of receipt of the Init message MUST be 1115 deleted. 1117 Note: a protocol instance that transition from Nothing state to 1118 Reception state has both received and sent an Initiate message. It 1119 MAY choose to finish the key exchange protocol and generate shared 1120 secret state according to the negotiated authentication method, or it 1121 may choose to delay such compuation until it receives an AUTH event 1122 in Reception state. 1124 6.3.3.2. Initiation State 1126 In Initiation state a protocol instance has initiated the IKE 1127 protocol to a peer. An INIT event causes the instance to leave 1128 Initiation state, and a TM event causes it to remain in Initiation 1129 state. 1131 When a protocol instance in Initiation state receives an INIT event, 1132 it signifies receipt of an Initiate message from the peer. The 1133 protocol instance first cancels the retransmission timer and then 1134 processes the Init message according to Section 6.1.1.2. If 1135 processing indicates that the message was discarded, the protocol 1136 instance sets the TM timer and remains in Initiation state. If 1137 processing indicates a failure, the protocol instance deletes all 1138 state it has created or retained and transitions back to Nothing 1139 state. Otherwise, processing is successful and the protocol instance 1140 shall finish the key exchange protocol and generate shared secret 1141 state according to the negotiated authentication method. It then 1142 increments the committed counter and generates an Auth message for 1143 the peer according to Section 6.1.2.1, transmits the message to the 1144 peer, sets the retransmission timer and transitions to state Done. 1146 When a protocol instance in Initiation state receives a TM event it 1147 indicates that the retransmission timer has expired. If the retrans 1148 counter is higher than the retransmission threshold it indicates 1149 failure of the protocol. In this case the protocol instance deletes 1150 all state it has created or retained and transitions back to Nothing 1151 state. If the retrans counter is not greater than the retransmission 1152 threshhold, the Init message that was transmitted to the peer as part 1153 of transitioning into Initiation state is sent again to the peer, the 1154 retrans counter is incremented and the protocol instance remains in 1155 Initiation state. 1157 6.3.3.3. Reception State 1159 In Reception state a protocol instance is acting as the traditional 1160 "responder" in the IKE protocol. It has both sent and received an 1161 Init message. An AUTH event causes the instance to leave Reception 1162 state, and both an INIT and a TM event cause it to remain in 1163 Reception state. 1165 When a protocol instance in Reception state receives an INIT event it 1166 signifies that the Init message it sent in order to transition into 1167 Reception state was not received by the peer. When it receives a TM 1168 event it indicates that its retransmission timer has expired. For an 1169 INIT event, the protocol instance first cancels the retransmission 1170 timer, after that the behavior a protocol instance takes is the same 1171 for an INIT or TM event. The instance retransmits the Init message 1172 it sent to the peer in order to transition in to Reception state, it 1173 sets its retransmission timer, and it remains in Reception state. 1175 When a protocol instance in Reception state receives an AUTH event it 1176 signifies reception of an Auth message from its peer. First the 1177 protocol instance cancels its retransmission timer. Next, if the 1178 protocol instance has not finished the key exchange protocol (see the 1179 note in Section 6.3.3.1) and generated a shared secret it does so 1180 here. It then sets the reauth counter to the value of the 1181 "committed" field in the processed Auth messages, sets its committed 1182 counter to negative one (-1), generates an Auth message for the peer 1183 according to Section 6.1.2.1, transmits the message to the peer, 1184 installs the IPsec SAs (per Section 6.2) and transitions to Done 1185 state. Note that the retransmission timer is not set. 1187 6.3.3.4. Done State 1189 Done state is the final state of the state machine. An initiator 1190 arrives in Done state after it has sent both of its messages to the 1191 peer and awaits a final Auth message. A responder arrives in Done 1192 state after it has sent and received both messages. To address the 1193 possibility of dropped packets and retransmission there are several 1194 events that can happen in Done state. Regardless of the event, 1195 though, after a state machine enters Done state it never leaves Done 1196 state. 1198 When a protocol in Done state receives an INIT event, it signfies the 1199 receipt of a retransmitted Init message. Since the protocol has 1200 entered Done state it has already received and processed an Init 1201 message. If its committed counter is less than zero the protocol 1202 instance drops the Init message and remains in Done state. If its 1203 committed counter is not less than zero it cancels its retransmission 1204 timer, increments the committed counter, generates an Auth message, 1205 transmits the Auth message to the peer, sets its retransmission 1206 timer, and remains in Done state. 1208 When a protocol in Done state receives a TM event, it signiifies that 1209 a previously sent Auth message has not been replied to in a timely 1210 manner. In this case, the protocol instance, checks the 1211 retransmission counter. If it is greater than the thresh counter the 1212 protocol instance destroys all state associated with the current run 1213 of the protocol (including any IPsec SAs that it might have 1214 installed) and transitions back to Nothing state. If the 1215 retransmission counter is not greater than the thresh counter, the 1216 protocol instance increments the retransmission counter, increments 1217 the committed counter, generates an Auth message, transmits the Auth 1218 message to the peer, sets the retransmission counter, and remains in 1219 Done state. 1221 When a protocol instance in Done state receives an AUTH event it 1222 signifies the receipt of an Auth message from the peer. This could 1223 be in response to a message from the protocol instance or it could be 1224 a retransmission or the replay of an old Auth message. To prevent a 1225 storm of Auth messages going back and forth between protocol 1226 instances in Done state, the response to an AUTH message is 1227 conditional. If the committed counter is less than zero the protocol 1228 instance drops the received Auth message and remains in Done state. 1229 If the committed counter is not less than zero, the protocol instance 1230 cancels its retransmission timer and processes the Auth message. If 1231 processing of the Auth message fails the protocol instance sets the 1232 retransmission timer and remains in Done state. If processing of the 1233 Auth message succeeds, the value of the "committed" field in the 1234 received Auth message is checked. If it is not numerically greater 1235 than the reauth counter the message is dropped, the retransmission 1236 timer is set, and the protocol instance remains in Done state. If 1237 the "committed" field in the received Auth message is numerically 1238 greater than the reauth counter, the reauth counter is set to the 1239 value in the "committed" field, the committed counter is set to 1240 negative one (-1), and an Auth message is generated. The protocol 1241 instance then sends the Auth message to the peer, and installs the 1242 IPsec SAs (per Section 6.2) and remains in Done state. Note that the 1243 retransmission timer is not set. 1245 6.3.4. Cleaning Up Protocol Instances 1247 The state machine ensures that once each side has sent and received 1248 an Auth message it installs IPsec SAs. To handle potential lost 1249 messages and retransmissions of its final Auth message a protocol 1250 instance remains in for a period of time after it has installed its 1251 IPsec SAs. These stale protocol instances can have their state 1252 deleted and transitioned back to Nothing state after a sufficient 1253 period of time. This memo does not define what "sufficient" means 1254 but suggests that after installing IPsec SAs, a protocol instance 1255 waits at least the amount of time it would spend before 1256 retranmissions would cause it to expire. That is: 1258 wait = (thresh - retrans) * retrans-period 1260 where "retrans-period" is the amount of time that the retransmission 1261 timer is set for. This will ensure that either the protocol instance 1262 expires because it retransmitted too many times or it will expire 1263 because the protocol has naturally completed. 1265 6.4. IKEv3 Payload Formats 1267 All messages in the IKEv3 protocol consist of an IKE header followed 1268 by additional payloads which define the semantics of the message. 1269 All payloads contain the same generic header. The IKE header 1270 indicates the first payload that follows and the generic header of 1271 each payload indicates the payload, if any, that follows. In this 1272 fashion payloads are chained together to form messages. 1274 6.4.1. IKE header 1276 The IKE header contains two message identifiers, called Security 1277 Parameter Indicies (SPIs), one for the transmitter and one for the 1278 receiver, an indicator of the first payload of the message, 1279 versioning information, and the type of message, either an Init or an 1280 Auth. The format of the IKE header is shown in Figure 4. 1282 1 2 3 1283 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 | IKE SA Transmitter's SPI | 1286 | | 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 | IKE SA Receivers's SPI | 1289 | | 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 | First Payload | MjVer | MnVer | Message Type | Flags | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | Length | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 | | 1296 ~ ICV/SIV ~ 1297 ~ (presence conditional) ~ 1298 | | 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1301 Figure 4: IKE Header Format 1303 o Transmitter's SPI (8 octets) - A session identifier chosen by the 1304 transmitter of the message. 1306 o Receiver's SPI (8 octets) - A session identifier chosen by the 1307 receiver of the message. 1309 o First Payload (1 octet) - The type of payload that follows the 1310 header. See Figure 6. 1312 o Major Version (4 bits) - The major version of this version of 1313 IKE. Implementations based on this memo MUST set the major 1314 version to three (3). Reciept of an IKE message with a different 1315 Major Version is governed by the memo which defines the version. 1316 An implementation that is only compliant with this version of IKE 1317 MUST drop any message with a Major version other than three (3). 1319 o Minor Version (4 bits) - The minor version of this version of 1320 IKE. Implementations based on this memo MUST set the minor 1321 version to zero (0) on transmitted messages and ignore the Minor 1322 Version on received messages. 1324 o Message Type (1 octet) - The type of message being transmitted: 1325 an Init message is type one (1) and an Auth message is type (2). 1327 o Flags (1 octet) - A bitmask that indicates specific options for 1328 the message. The bits in this bitmask are as follows: 1330 +-+-+-+-+-+-+-+-+ 1331 |X|X|X|V|X|X|X|S| 1332 +-+-+-+-+-+-+-+-+ 1334 Bits indicated as 'X' MUST be cleared on transmission and ignored 1335 on reception. Setting a bit to one (1) indicates that the option 1336 applies and clearing the bit to zero (0) indicates the option 1337 does not apply. 1339 * V (Version) - This bit indicates that the transmitter is 1340 capable of speaking a higher major version number of the IKE 1341 protocol than the one indicated in the major version field of 1342 this header. 1344 * S (Secured) - This bit indicates that the message following 1345 this header is authenticated and encrypted. When this bit is 1346 set the ICV/SIV field in the header is present. 1348 o Length (4 octets) - an unsigned integer that indicates the length 1349 of the total IKE message (IKE header + all payloads) in octets. 1350 Note: if the 'E' bit in the Flags is set this length includes the 1351 conditional field to hold the Synthetic Initialization Vector/ 1352 MAC. 1354 o ICV/SIV (variable) - a conditional field that is present when the 1355 message following the header is secured. This field is the 1356 byproduct of authenticated encryption and is required for 1357 verified decryption. The exact format of the ICV/SIV field 1358 depends on the type of authenticated encryption used by the 1359 peers. 1361 6.4.2. Generic IKE payload header 1363 The Generic IKE payload header is used to demark and chain all 1364 payloads in a message. Each payload used in a message contains this 1365 header. The Generic IKE payload header is defined in Figure 5. 1367 1 2 3 1368 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | Next Payload | RESERVED | Payload Length | 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 Figure 5: IKE Header Format 1375 o Next Payload (1 octet) - Indicates the payload, if any, that 1376 follows the current payload. See Figure 6. 1378 o RESERVED (1 octet) - Unused by this version of IKE. It MUST be 1379 set to zero on all payloads in a transmitted message and ignored 1380 on all payloads in a received message. 1382 o Payload Length (2 octets) - An unsigned integer indicating the 1383 entire length of the current payload, including this generic 1384 header. 1386 Subsequently defined payloads are all shown with the generic header 1387 for completeness. Payload types listed here are current as of 1388 publication of this memo. Readers are encouraged to see [IKEV3IANA] 1389 for the latest values. 1391 Payload Type Notation Value 1392 ------------------------------------------------------------ 1393 No Next Payload 0 1394 IKE Attributes Payload IA 1 1395 Identity Payload ID 2 1396 Nonce Payload NO 3 1397 Key Exchange Payload KE 4 1398 Certificate Request Payload CR 5 1399 Certificate Payload CE 6 1400 Authentication Payload AU 7 1401 Address Indication AI 8 1402 Traffic Selector TS 9 1403 Security Assocation Payload SA 10 1404 Vendor Indication VE 11 1406 Figure 6: IKEv3 Payload Assignment 1408 The value "No Next Payload" SHALL only be used in the last payload of 1409 a message. 1411 6.4.3. IKE Attributes payload 1413 The IKE attributes payload lists a number of attributes that define 1414 the manner in which a run of the IKEv3 protocol occurs. Attributes 1415 consist of type-value tuples to identify the type of attribute and 1416 its particular value. These attributes are offered, not negotiated. 1417 See Section 6.1.1.2 for a description of the processing and potential 1418 rejection of an IA offer. The IA payload is defined in Figure 7. 1420 1 2 3 1421 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 | Next Payload | RESERVED | Payload Length | 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 | Attribute Number 1 Type | Attribute Number 1 Value | 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 ~ . . . ~ 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 | Attribute Number N Type | Attribute Number N Value | 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 Figure 7: IA Payload 1434 The following attributes types are defined and are indicated by 1435 assigning the indicated number to the Attributes Number Type 1436 field: 1438 1. Authentication Method 1440 2. Authenticated Encryption Mode 1442 3. Hash Algorithm 1444 4. Diffie-Hellman Group 1446 All other values are reserved to IANA. 1448 When the Attribute Type indicates "Authentication Method", the 1449 following values are defined: 1451 1. Digital Signatures 1453 2. Pre-shared Key 1455 All other values are reserved to IANA. 1457 When the Attribute Type indicates "Authentication Encryption Mode", 1458 the following values are defined: 1460 1. AES in Synthetic Initialization Mode ([RFC5297]) with a 256-bit 1461 key 1463 2. AES in Synthetic Initialization Mode ([RFC5297]) with a 512-bit 1464 key 1466 All other values are reserved to IANA. 1468 When the Attribute Type indicates "Hash Algorithm, the following 1469 values are defined: 1471 1. SHA-256 ([RFC4634]) 1473 2. SHA-512 ([RFC4634]) 1475 All other values are reserved to IANA. 1477 When the Attribute Type indicates "Diffie-Hellman Group", the 1478 attribute values are taken from the "Diffie-Hellman Group Transform 1479 IDs" from [IKEV2IANA]. 1481 6.4.4. Identity Payload 1483 The ID payload is used to convey the identity that is to be 1484 authenticated by the remote peer. 1486 1 2 3 1487 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | Next Payload | RESERVED | Payload Length | 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 | ID Type | RESERVED | 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 | | 1494 ~ Identification Data ~ 1495 | | 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 Figure 8: ID Payload 1500 The following ID Types are defined: 1502 ID Type Value Description 1503 ------- -------------- ---------------------------------------------- 1504 1 ID_IPV4_ADDR A single four (4) octet IPv4 address 1505 2 ID_FQDN A fully-qualified domain name string. An 1506 ID_FQDN string MUST NOT contain any 1507 terminators (e.g. NULL, CR, etc.). All 1508 characters in the ID_FQDN are ASCII. 1509 3 ID_RFC822_ADDR A fully-qualified RFC 822 email address 1510 string. An ID_RFC822_ADDR string MUST NOT 1511 contain any terminators (e.g. NULL, CR, 1512 etc.). This field SHOULD be treated as UTF-8 1513 encoded text. 1514 4 ID_IPV6_ADDR A single sixteen (16) octet IPv6 address 1515 5 ID_DER_ASN1_DN The binary Distinguished Encoding Rules (DER) 1516 encoding of an ASN.1 X.500 Distinguished Name. 1517 See [RFC5280]. 1518 6 ID_DER_ASN1_GN The binary DER encoding of an ASN.1 X.500 1519 GeneralName. See [RFC5280]. 1520 7 ID_BLOB_ID An opaque octet stream used for identity 1521 obfuscation. The two parties to the exchange 1522 MUST agree in an out-of-band fashion on how to 1523 map a Blob ID to an unobfuscated identity. 1525 Table 1 1527 Identification Data is a variable-length field that contains the 1528 identity of the specified type. 1530 6.4.5. Nonce Payload 1532 1 2 3 1533 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 | Next Payload | RESERVED | Payload Length | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 ~ Nonce of the transmitter ~ 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1540 Figure 9: NO Payload 1542 6.4.6. Key Exchange Payload 1544 The KE payload is used to pass data used to perform the key exchange 1545 portion of the IKEv3 protocol (see Section 5). The body of the KE 1546 payload is authentication method specific. When doing The KE payload 1547 is authentication method specific. authentication using digital 1548 signatures, the body of the KE payload is a Diffie-Hellman public 1549 value. When doing PSK authentication, the body of the KE payload is 1550 a concatentation of the Commit and Confirm portions of the Dragonfly 1551 key exchange. 1553 1 2 3 1554 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 | Next Payload | RESERVED | Payload Length | 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 | | 1559 ~ Key exchange data ~ 1560 | | 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 Figure 10: KE Payload 1565 The key exhange data is a variable-length field that contains data to 1566 be transmitted to the remote peer to perform a cryptographic key 1567 exchange. 1569 6.4.7. Certificate Payload 1571 The CE payload is used to convey a public key which will be used for 1572 authentication to a remote peer. The public key can be certified or 1573 raw. 1575 1 2 3 1576 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 | Next Payload | RESERVED | Payload Length | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | Encoding Type | | 1581 +-+-+-+-+-+-+-+-+ | 1582 ~ (Cerfified) Public Key Data ~ 1583 | | 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 Figure 11: CE Payload 1588 Encoding Description 1589 -------- ------------------------------------------------------------ 1590 1 A DER-enocded X.509 certificate 1591 2 Subject public key info for a raw key encoded according to 1592 [RFC5480] 1593 3 Subject public key info for a raw key encoded accoding to 1594 [RFC3279] 1596 Table 2 1598 The Public key data is a variable-length field that contains the 1599 public key of the specified encoding. 1601 6.4.8. Certificate Request Payload 1603 The CR payload is used to request a certificate from a remote peer. 1604 The transmitter indicates a preference for the type of certificate 1605 using by setting the Encoding type according to Table 2. The 1606 transmitter SHOULD indicate a trusted Certification Authority for 1607 certified pubilc keys. 1609 1 2 3 1610 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 | Next Payload | RESERVED | Payload Length | 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 | Encoding Type | | 1615 +-+-+-+-+-+-+-+-+ | 1616 ~ Certification Authority ~ 1617 ~ (optional) ~ 1618 | | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 Figure 12: CR Payload 1623 The Certificate Authority field, when present, is a variable-length 1624 field that contains the DER encoding of an ASN.1 X.509 IssuerName. 1626 6.4.9. Authentication Payload 1628 The AU payload contains data that authenticates a remote peer. The 1629 content of the body of an AU payload is either a digital signature 1630 (see Section 5.1.2) when authenticating with digital signatures, or a 1631 keyed message authentication function using the negotiated hash 1632 algorithm (see Section 5.2.4) when authenticating with a PSK. 1634 1 2 3 1635 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 | Next Payload | RESERVED | Payload Length | 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 | | 1640 ~ Sig or MAC ~ 1641 | | 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 Figure 13: AU Payload 1646 Sig or MAC is a variable-length field that contains either a digital 1647 signature of a message authentication code. 1649 6.4.10. Address Indication Payload 1651 The AI payload is used to convey the local view of addressing and 1652 port selection to the remote peer for the purposes of NAT detection. 1654 1 2 3 1655 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1657 | Next Payload | RESERVED | Payload Length | 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1659 | Address Type | Port | 1660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 | | 1662 ~ Address ~ 1663 | | 1664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1666 Figure 14: AI Payload 1668 Address Types have the following meaning: 1670 Address Type Description 1671 -------------- ------------------------------------------------------ 1672 1 The Address field is a single four (4) octet IPv4 1673 address 1674 2 The Address field is a single sixteeen (16) octet IPv6 1675 address 1677 Table 3 1679 All other Address Types are reserved and MUST NOT be used. 1681 6.4.11. Traffic Selecor Payload 1683 The TS payload is used to convey a set of traffic selectors used to 1684 identify traffic flows for processing by IPsec security services. 1686 1 2 3 1687 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1689 | Next Payload | RESERVED | Payload Length | 1690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1691 | # of Tr Sels | RESERVED | 1692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1693 | | 1694 ~ Sequence of one or more ~ 1695 ~ Traffic Selectors ~ 1696 | | 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1699 Figure 15: TS Payload 1701 The traffic selectors conveyed to a peer are determined by the local 1702 Security Policy Database (see [RFC4301]). They define the data that 1703 MUST be protected by IPsec by individual flow. Each Traffic Selector 1704 in the set is defined by the following structure: 1706 1 2 3 1707 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1709 | Selector Type | IP Protocol ID| Traffic Selector Length | 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | Start Port | End Port | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 | | 1714 ~ Starting Address ~ 1715 | | 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1717 | | 1718 ~ Ending Address ~ 1719 | | 1720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 Figure 16: Traffic Selector 1724 o Select Type (one octet) - either a one (1) to indicate an 1725 IPV4_ADDR_RANGE or two (2) to indicate an IPV6_ADDR_RANGE. All 1726 other types are invalid and MUST be rejected. 1728 o IP Protocol ID (one octet) - indicates the associated IP protocol 1729 (such as UDP, TCP, and ICMP). A value of zero (0) means that the 1730 traffic selector convers all protocols. 1732 o Traffic Selector Length (two octets) - the total length of the 1733 selector, including this sub header. 1735 o Start Port (two octets) - the lowest port in a range of ports 1736 that are covered by this traffic selector. A value of zero (0) 1737 means that the traffic selector covers all ports. ICMP and 1738 ICMPv6 Type and Code values, as well as Mobile IP version 6 1739 (MIPv6) mobility header (MH) Type values, are represented 1740 according to Section 4.4.1.1 of [RFC4301]. ICMP Type and Code 1741 values are treated as a single 16-bit integer port number, with 1742 Type in the most significant 8 bits and Code in the least 1743 significant 8 bits. MIPv6 MH Type and Code values are treated as 1744 a single 16-bit integer port number with Type in the most 1745 significant 8 bits and the least signficant 8 bits set to zero. 1747 o End Port (two octets) - the highest port in a range of ports that 1748 are covered by this traffic selector. For protocols for which 1749 port is undefined (including protocol 0), or if all ports are 1750 allowed, this field MUST be 65535. ICMP and ICMPv6 Type and COde 1751 values, as well as MIPv6 MH Type values, are represented in this 1752 field as specified in Section 4.4.1.1 of [RFC4301]. ICMP Type 1753 and COde values are treated as a single 16-bit port number with 1754 Type in the most significant 8 bits and Code in the least 1755 significant 8 bits. MIPv6 MH Type values are treated as a single 1756 16-bit integer port number with Type in the most significant 8 1757 bit and the least significant 8 bits set to zero. 1759 o Starting Address (variable) - the lowest address in a range of 1760 addresses that are covered by this traffic selector. This field 1761 will be either sixteen (16) octets or four (4) octets depending 1762 on whether the Selector Type was IPV6_ADDR_RANGE or 1763 IPV4_ADDR_RANGE, respectively. 1765 o Ending Address (variable) - the highest address in a range of 1766 addresses that are covered by this traffic selector. This field 1767 will be either sixteen (16) octets or four (4) octets depending 1768 on whether the Selector Type was IPV6_ADDR_RANGE or 1769 IPV4_ADDR_RANGE, respectively. 1771 6.4.12. Security Association Payload 1773 The SA payload indicates the type of protection that IPsec will apply 1774 to the data that is covered by the Traffic Selector(s) in the TS 1775 payload. Protection is described as a number of attributes with each 1776 attribute consisting of a type-value tuple to identify the type of 1777 attribute and its particular value. 1779 1 2 3 1780 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 | Next Payload | RESERVED | Payload Length | 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 | SPI | 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 | Attribute Number 1 Type | Attribute Number 1 Value | 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1788 ~ . . . ~ 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 | Attribute Number N Type | Attribute Number N Value | 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 Figure 17: SA Payload 1795 SPI (4 octets) - the Security Parameter Index that the transmitter of 1796 the SA payload will use to identify the resulting security 1797 association for received IPsec-protected packets. 1799 The following attribute types are defined: 1801 1. Encryption Algorithm 1803 2. Integrity Algorithm 1805 3. Extended Sequence Numbers 1807 If the Encryption Algorithm attribute is present in an SA payload the 1808 SA SHALL be for ESP. If it is absent the SA SHALL be for AH. The 1809 Integrity Algorithm attribute is OPTIONAL for ESP and MANDATORY for 1810 AH. The Extended Sequence Number attribute is OPTIONAL. 1812 The attribute values for the Encryption Algorithm attribute are 1813 defined in [IKEV2IANA] in the "Encryption Algorithm Transform IDs" 1814 table. The attribute values for the Integrity Algorithm attribute 1815 are defined in [IKEV2IANA] in the "Integrity Algorithm Transform IDs" 1816 table. The attribute values for the Extended Sequence Numbers 1817 attribute are defined in [IKEV2IANA] in the "Extended Sequence 1818 Numbers Transform IDs". 1820 6.4.13. Vendor Indication Payload 1822 The VI payload allows vendors of IKEv3 products to identify each 1823 other during the protocol. 1825 1 2 3 1826 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 | Next Payload | RESERVED | Payload Length | 1829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1830 | | 1831 ~ Vendor Identifying Blob ~ 1832 | | 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1835 Figure 18: VI Payload 1837 The Vendor Identifying Blob is a variable length field that contains 1838 information to identify the vendor of the transmitter of the payload. 1839 No registry for vendor identification is used and it is advised that 1840 vendors produce an opaque blob that will be different for each run of 1841 the protocol to identify themselves. This can be accomplished, for 1842 instance, by hashing the transmitter and receiver SPIs and/or the IP 1843 addresses of the peers with a vendor-specific constant. 1845 7. Acknowledgements 1847 Portions of the payload descriptions (e.g. Traffic Selector payload) 1848 were lifted from [RFC5996]. The author thanks the editors of that 1849 document and the IPsecME Working Group that produced that document. 1851 8. IANA Considerations 1853 This section is incomplete. 1855 9. Security Considerations 1857 This section is incomplete. 1859 10. References 1861 10.1. Normative References 1863 [IKEV2IANA] 1864 "Internet Key Exchange Version 2 (IKEv2) Parameters", 1865 . 1867 [IKEV3IANA] 1868 "Internet Key Exchange Version 3 (IKEv3) Parameters", 1869 . 1871 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1872 Hashing for Message Authentication", RFC 2104, 1873 February 1997. 1875 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1876 Requirement Levels", BCP 14, RFC 2119, March 1997. 1878 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 1879 Identifiers for the Internet X.509 Public Key 1880 Infrastructure Certificate and Certificate Revocation List 1881 (CRL) Profile", RFC 3279, April 2002. 1883 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1884 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1885 RFC 3948, January 2005. 1887 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 1888 (SHA and HMAC-SHA)", RFC 4634, July 2006. 1890 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1891 Housley, R., and W. Polk, "Internet X.509 Public Key 1892 Infrastructure Certificate and Certificate Revocation List 1893 (CRL) Profile", RFC 5280, May 2008. 1895 [RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) 1896 Authenticated Encryption Using the Advanced Encryption 1897 Standard (AES)", RFC 5297, October 2008. 1899 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 1900 "Elliptic Curve Cryptography Subject Public Key 1901 Information", RFC 5480, March 2009. 1903 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1904 Curve Cryptography Algorithms", RFC 6090, February 2011. 1906 10.2. Informative References 1908 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1909 (IKE)", RFC 2409, November 1998. 1911 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1912 Internet Protocol", RFC 4301, December 2005. 1914 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1915 RFC 4306, December 2005. 1917 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 1918 Implementation Guidelines", RFC 4718, October 2006. 1920 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1921 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1922 RFC 5996, September 2010. 1924 Author's Address 1926 Dan Harkins (editor) 1927 Aruba Networks 1928 1322 Crossman avenue 1929 Sunnyvale, Californaia 94089 1930 United States of America 1932 Phone: +1 408 227 4500 1933 Email: dharkins@arubanetworks.com