idnits 2.17.1 draft-sheffer-autovpn-00.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 (February 4, 2014) is 3734 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Sheffer 3 Internet-Draft Porticor 4 Intended status: Informational Y. Nir 5 Expires: August 8, 2014 Check Point 6 February 4, 2014 8 The AutoVPN Architecture 9 draft-sheffer-autovpn-00 11 Abstract 13 This document describes the AutoVPN architecture. AutoVPN allows 14 IPsec security associations to be set up with no prior configuration, 15 using the "leap of faith" paradigm. The document defines a 16 lightweight protocol for negotiating such opportunistic encryption 17 either directly between hosts or between two security gateways on the 18 path. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 8, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Architecture and Protocol Overview . . . . . . . . . . . . . 4 57 4. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . 6 58 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 7 59 5.1. ICMP Encoding . . . . . . . . . . . . . . . . . . . . . . 7 60 5.2. UDP Encoding . . . . . . . . . . . . . . . . . . . . . . 7 61 5.3. Protocol Payloads . . . . . . . . . . . . . . . . . . . . 8 62 5.4. Version Payload . . . . . . . . . . . . . . . . . . . . . 9 63 5.5. Nonce Payloads . . . . . . . . . . . . . . . . . . . . . 10 64 5.6. NAT-Detect Payload . . . . . . . . . . . . . . . . . . . 10 65 6. Error Handling and Reliability . . . . . . . . . . . . . . . 10 66 7. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 8. IKE Protocol Considerations . . . . . . . . . . . . . . . . . 11 68 8.1. New IKE Payloads . . . . . . . . . . . . . . . . . . . . 12 69 8.1.1. AutoVPN Nonce . . . . . . . . . . . . . . . . . . . . 12 70 8.1.2. Contact Details . . . . . . . . . . . . . . . . . . . 12 71 8.2. AUTOVPN_SHARED_SECRET Notification . . . . . . . . . . . 12 72 9. Security Policy . . . . . . . . . . . . . . . . . . . . . . . 12 73 9.1. Certificate States . . . . . . . . . . . . . . . . . . . 12 74 9.2. Certificate Rollover and Permanent Association . . . . . 14 75 9.3. Certificate Conflicts . . . . . . . . . . . . . . . . . . 14 76 9.4. Fallback to Clear . . . . . . . . . . . . . . . . . . . . 15 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 80 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 13.1. Normative References . . . . . . . . . . . . . . . . . . 15 82 13.2. Informative References . . . . . . . . . . . . . . . . . 16 83 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 16 84 A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 Appendix B. Implementation Considerations . . . . . . . . . . . 17 86 B.1. Address Authorization . . . . . . . . . . . . . . . . . . 17 87 B.2. Multiple Interfaces and Alternative Gateways . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 In the last few years, there have been several attempts to define an 93 opportunistic encryption architecture, where network traffic is 94 confidentiality-protected, even in the absence of proper 95 authentication of the peers. This protection is often accompanied by 96 continuity of identity, i.e. although the identity may not be 97 authenticated, it is verified to remain unchanged between multiple 98 protocol sessions, and over long periods (days/weeks). This initial 99 protection may be enhanced at a later stage, as peers gain stronger 100 trust in each other's identity. A term which is often used to denote 101 this policy is "leap of faith". 103 In the IPsec space, these attempts culminated in the BTNS (Better 104 Than Nothing Security) working group's specifications. The BTNS 105 working group produced a number of documents, including [RFC5386] and 106 [RFC5387]. In addition, the earlier [RFC4322] describes 107 Opportunistic Encryption, as implemented in various dialects of Linux 108 (the history of Linux OE is summarized in a long post by Paul Wouters 109 [oe-history]). However these specifications focus on the 110 architectural IPsec implications, and provide insufficient context to 111 implement the behavior described in the current document. "Leap of 112 faith" has never been fully specified in the IPsec context, or when 113 specified, assumes mechanisms that are still not widely deployed. 115 Similarly to many security architectures, a well designed 116 opportunistic encryption solution requires both a robust protocol, 117 and a user interaction component that allows the user to understand 118 the exact security guarantees available at any time, so that the user 119 may add external inputs about trustworthiness of communication peers 120 while staying away from the "just press OK" mentality. 122 This document describes the AutoVPN architecture, an opportunistic 123 encryption extension to the Internet Key Exchange v2 (IKEv2 - 124 [RFC5996]) for IPsec VPN. 126 Some of the requirements behind this protocol are: 128 o It should be suitable for business-to-business traffic, and 129 therefore for deployment on the open Internet. 131 o It should be robust, efficient and network friendly enough to be 132 enabled by default. 134 o It should be deployable on (existing) security gateways, rather 135 than requiring changes to hosts. 137 o It should also work on hosts that are not protected by gateways, 138 i.e. hosts that are themselves IPsec endpoints. 140 o It should require zero configuration. Some limited level of 141 security should be provided by devices which are not configured. 143 o After-the-fact security: the security guarantees can be improved 144 at a later time, possibly using out-of-band means. 146 o The protocol should coexist with regular IPsec, with no 147 degradation in security. 149 o The protocol should provide the best possible security given the 150 imperfections of today's Internet. In particular, it should not 151 rely on the deployment of DNS Security, anti spoofing mechanisms 152 or routing security. 154 o Small gateways, as well as software VPN clients, are often behind 155 NAT. This scenario should be supported. 157 2. Terminology 159 We use the term "initiator" for the gateway through which came the 160 original traffic. The gateway may not be the initiator of the new 161 protocol described below. The other gateway is the "responder". 162 Note that these terms correspond to the gateways' behavior with 163 respect to IKE negotiation. 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in [RFC2119]. 169 3. Architecture and Protocol Overview 171 The protocol creates an IPsec tunnel to protect traffic which would 172 otherwise be transmitted in the clear. What follows is a high level 173 description of the sequence of operations. 175 We use H1 and H2 to denote two hosts (endpoints), and G1 and G2 to 176 denote two IPsec gateways, protecting H1 and H2 respectively. This 177 setup is shown in Figure 1 below. The solution described here is 178 also applicable when one or both hosts is collocated with its 179 respective gateway. Unfortunately it cannot be optimized for these 180 cases, since source IP addresses can always be spoofed. 182 +--------+ +---------+ +---------+ +--------+ 183 | | | | | | | | 184 | Host | | Gateway | / -------- \ | Gateway | | Host | 185 | H1 |---| G1 |---| Internet |---| G2 |---| H2 | 186 | | | | \ -------- / | | | | 187 +--------+ +---------+ +---------+ +--------+ 189 Figure 1: Deployment Architecture 191 Initially, only H1 knows of H2's address. The protocol below allows 192 both intervening gateways to discover each other, and to gain 193 assurance that each one is on-path of the opposite host, i.e. it can 194 see traffic addressed to the respective host, and can respond to such 195 traffic. 197 We assume that both G1 and G2 contain access control functionality, 198 as required by the IPsec architecture, and that both allow some clear 199 traffic between H1 and H2. 201 The message sequence below is motivated to a great extent by the need 202 to cater to NAT devices in front of G1, the original initiator. It 203 is assumed that correctly implemented NAT devices will perform 204 correct reverse translation of ICMP messages. However we cannot 205 assume that they handle correctly ICMP messages of an unknown type. 207 Another major consideration is which side should drive the exchange. 208 We have chosen the responder side (G2), since in an Internet where 209 most traffic uses HTTP, the responder side knows best which traffic 210 should be protected. 212 Lastly, we could have saved one round trip by allowing G2 to spoof 213 H2's address. We believe this would have been ill advised. 215 The flow of messages is depicted in Figure 2. 217 o H1 creates a network connection to H2, for example by sending a 218 TCP SYN packet. H2 replies normally to H1. 220 o G2 intercepts the reply packet, but lets it pass through. The 221 connection proceeds normally, possibly including data packets. 223 o G2 sends a Probe Request message, addressed to H1. 225 o G1 intercepts the Probe Request, does not forward it, and sends a 226 Probe Response, addressed to H2. Note that if H1 is NOT protected 227 by a gateway, it will receive the Probe Request message and 228 therefore the message should be designed to have no effect on 229 innocent receivers. 231 o G2 intercepts the Probe Response, does not forward it, and sends a 232 Probe Complete, addressed to G1. 234 o G1 now initiates an IKE_SA_INIT exchange to G2. This message 235 includes payloads that can be correlated with the previous 236 messages. 238 o G1 and G2 negotiate an IPsec SA, potentially for all traffic 239 between H1 and H2. 241 o Both G1 and G2 now move the traffic between H1 and H2 into the new 242 SA. 244 H1 G1 G2 H2 245 ==== ==== ==== ==== 246 || || Syn || || 247 ||----------------------------------------------------------------->|| 248 || || Ack || || 249 ||<-----------------------------------------------------------------|| 250 || || Unencrypted traffic || || 251 ||<================================================================>|| 252 || || || || 253 || || || || 254 || || Probe Request (ICMP) || || 255 ||<- - - - - - - -||<-----------------------------|| || 256 || || Probe Response (UDP/4500) || || 257 || ||----------------------------->||- - - - - - - ->|| 258 || || Probe Complete (ICMP) || || 259 || ||<-----------------------------|| || 260 || || IKE Message #1 || || 261 || ||----------------------------->|| || 262 || || IKE Signaling || || 263 || ||<============================>|| || 264 || || Protected traffic || || 265 ||<==============>||<============================>||<==============>|| 267 Figure 2: Message Sequence 269 4. Protocol Exchanges 271 AutoVPN consists of a 3-way probing protocol, followed by a slightly 272 extended IKEv2 exchange. 274 The normal execution sequence of the protocol is as follows. G2 275 generates a fresh, randomly generated value Nonce-R, and sends to H1: 277 Probe Request: Version, Nonce-R, NAT-Detect 279 G1 intercepts the received message and does not forward it to H1. G1 280 MAY verify that the message corresponds to an ongoing connection, 281 using the packet fragment contained in the ICMP envelope. G1 282 generates a fresh, random Nonce-I and sends to H2: 284 Probe Response: Version, Nonce-I, Nonce-R 286 where the content of Nonce-R is copied from the request. G2 287 intercepts this message, and does not forward it to H2. G2 MUST 288 verify that Nonce-R is valid, and silently ignore the message 289 otherwise. G2 replies with: 291 Probe Complete: Version, Nonce-I, Nonce-R 293 G1 MUST check the validity of Nonce-I and Nonce-R. Finally, G1 sends 294 an IKEv2 IKE_SA_INIT message to G2, containing a copy of the received 295 Nonce-R. 297 5. Message Format 299 The AutoVPN protocol messages consist of a sequence of type-length- 300 value (TLV) payloads. The messages are encoded in two different base 301 protocols: ICMP and UDP over port 4500. 303 The Probe Request and Probe Complete messages MUST be encoded within 304 ICMP. The Probe Response message MUST be encoded within UDP. 306 5.1. ICMP Encoding 308 Each payload is encoded as an ICMP Extension Object, as per 309 [RFC4884]. ICMP Error messages contain a copy of (part of) the 310 original packet, and this is used to associate the ICMP message with 311 the original clear traffic. ICMP header fields are populated as 312 follows: 314 o Type is "Parameter Problem". 316 o Code is the value 1. 318 o The Checksum field MUST be computed, as per [RFC0792]. 320 o The new Length field is defined in [RFC4884]. 322 In the Extension Object Headers, Class-Num is TBD by IANA, and C-Type 323 is the Type value defined for each payload below. 325 5.2. UDP Encoding 327 In this encoding, all payloads are simply concatenated following the 328 Preamble. Each payload is preceded by a payload header, as defined 329 in Section 5.3. 331 The generic Preamble format is described in the next figure. 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | IP Header... | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | UDP Header... | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | SPI (16 bytes, value TBD by IANA) | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Figure 3: AutoVPN Preamble 345 The Probe Response protocol message has 4500 as its destination port. 346 The protocol reuses the IKE/IPsec port 4500, however it is neither 347 IKE nor IPsec. All three can coexist, and are distinguished using 348 the SPI value. The specific SPI value will be allocated out of the 349 "reserved" SPI space. 351 5.3. Protocol Payloads 353 An AutoVPN payload is encoded as an ICMP Extension Object or within a 354 UDP message. When using UDP, the generic payload header is described 355 in the next figure: 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Type | 0 | Length | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Value... | 363 +...............................................................+ 364 | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Figure 4: Payload Header 369 Type: 371 One of the payload types listed below. 373 Length: 375 The payload length in octets, including this header. 377 The following payload types are defined: 379 +------------+---------+--------------------------------------------+ 380 | Name | Value | Definition | 381 +------------+---------+--------------------------------------------+ 382 | Unused | 0 | | 383 | Version | 1 | Generic information about the current | 384 | | | message | 385 | Nonce-I | 2 | Initiator's nonce | 386 | Nonce-R | 3 | Responder's nonce | 387 | NAT-Detect | 4 | NAT detection information | 388 | | 4-127 | Reserved to IANA | 389 | | 128-255 | Reserved for private use | 390 +------------+---------+--------------------------------------------+ 392 5.4. Version Payload 394 This payload is formatted as follows: 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Version | Message Type | Reserved | Vendor ID | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 ~ ~ 402 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 403 ~ | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 Figure 5: Version Payload 408 The header contains the following fields: 410 Version: 412 MUST be 0x01 for this version of the protocol. 414 Message Type: 416 1 for Probe Request, 2 for Probe Response, 3 for Probe Complete. 417 Other values are reserved to IANA. 419 Reserved: 421 MUST be sent as 0, and ignored by the receiver. 423 Vendor ID: 425 This field is optional and of variable length, possibly 0. It MAY 426 contain a string uniquely identifying the vendor (e.g. 427 "example.com"), or a binary string that is statistically unique 428 (e.g. the SHA-1 hash of "we support the XX extension"). 430 5.5. Nonce Payloads 432 Nonces are random or unpredictable values that enable the entity that 433 generated them to recognize them as valid when it receives them 434 again. Nonces MAY be used to encode state, in order to enable 435 stateless implementations of this protocol. The length of each nonce 436 (excluding the payload header) MUST be between 8 and 64 octets, 437 inclusive. 439 One possible way to construct the nonce is 441 key-ID || HMAC-SHA256(K, gateway-IP || packet-fragment) 443 where K is a secret key known only to the sender, and key-ID 444 identifies the key, enabling smooth roll-over of keys. Packet- 445 fragment is the same portion of the packet as returned in an ICMP 446 response, i.e. the IP header and the 8 octets that follow it. 448 5.6. NAT-Detect Payload 450 This payload consists of a 4-octet obfuscated IPv4 address, followed 451 by a 2-octet port number. The address is obfuscated by a XOR 452 operation with 0x0F0F0F0F, with the intention of defeating over-eager 453 NAT devices which might try to rewrite the packet. The address and 454 port are the source address/port of the original (clear) packet, as 455 seen by the remote gateway (G2). The IP protocol (e.g. UDP or TCP) 456 is inferred from the packet fragment included in the ICMP message 457 containing this payload. 459 6. Error Handling and Reliability 461 The AutoVPN protocol is UDP and ICMP based, and therefore per-message 462 reliability is not guaranteed. Both sides MAY retransmit the ICMP 463 and UDP messages, but MUST NOT do so more than twice (total of 3 464 messages). The gateway (G2) that sends the first ICMP message MUST 465 NOT retry a particular peer more than once every 24 hours. 467 The protocol does not include any error messages. If a peer does not 468 accept a particular message for any reason, it MUST silently drop it. 469 For forward compatibility, a receiver SHOULD process incoming 470 messages even if they contain payloads that it does not understand, 471 and SHOULD ignore these payloads. 473 7. NAT Considerations 475 The current version of the protocol allows both sides to detect a NAT 476 being performed between the gateways. Detection takes place during 477 the probing phase. However this scenario raises several issues, 478 which require further investigation before a useful solution can be 479 proposed: 481 o If traffic from a host which is behind NAT (H1) is inserted 482 directly into an IPsec tunnel, it will emerge as-is on the other 483 side, and the receiving host might see a non-routable [RFC1918] 484 source address. 486 o The initiating gateway may not have enough information to 487 formulate its IKE Traffic Selector payload (TSi). 489 A solution that can be considered is for G1 to request a Tunnel Inner 490 Address using an IKE Configuration Payload, and to perform NAT on 491 traffic originating from H1 so that it appears to be sourced from 492 that address. One of the issues with this solution is that the 493 initial clear connection will necessarily be broken because of the 494 address change. 496 We note that the protocol can be implemented correctly on a gateway 497 that performs the NAT function itself. 499 8. IKE Protocol Considerations 501 The AutoVPN protocol imposes a few requirements on the IKE peers: 503 o Both peers MUST use a certificate to authenticate. In many cases 504 this is expected to be a self-signed certificate. But see also 505 Section 9.2. 507 o The peers MUST NOT negotiate any IPsec protocol, other than ESP in 508 tunnel mode. 510 o Each peer MUST offer only a single IP address in its negotiated 511 traffic selector. This IP address MUST be identical to the one 512 the gateway has proven authorization for. This MUST also be 513 validated by the opposite peer. Per policy, traffic selectors MAY 514 be even narrower, e.g. referring to specific protocol ports. 516 8.1. New IKE Payloads 518 This protocol defines several new IKE payloads. 520 8.1.1. AutoVPN Nonce 522 This payload has the payload type TBD by IANA. It MUST only be used 523 in the first message of the IKE_SA_INIT exchange. The payload 524 contains an exact copy of the Nonce-R AutoVPN payload, without the 525 AutoVPN payload header. 527 8.1.2. Contact Details 529 This payload has the payload type TBD by IANA. It SHOULD be sent by 530 both peers during the IKE_AUTH exchange. The payload contains a 531 human readable UTF-8 string which is designed to assist the person 532 managing the opposite protocol peer in verifying the sender's true 533 identity. An example string is: 535 This gateway is operated by Example Inc. To validate our identity, 536 you may wish to obtain our public key's fingerprint from our Web 537 site, at https://www.example.com/autovpn. Or you may wish to 538 contact the network administrator at 1-616-555-1212 to get the 539 fingerprint. Please compare this value with the fingerprint value 540 displayed by your gateway. 542 For obvious security reasons, this string MUST be rendered as plain 543 text, and in particular MUST NOT be rendered as HTML. 545 8.2. AUTOVPN_SHARED_SECRET Notification 547 This notification, whose value is TBD by IANA, contains no data. It 548 signifies that an AutoVPN shared secret MUST be created by the two 549 IKE peers. See Section 9.2 for details. 551 9. Security Policy 553 This section describes the AutoVPN security policy, and should be 554 viewed as an extension of [RFC4301]. 556 9.1. Certificate States 558 AutoVPN defines a state for each peer gateway's certificate. A 559 certificate may be in one of the following states (Figure 6): 561 o Unknown. This may also be a certificate which had been manually 562 removed, through a manual operation or for a number of reasons 563 listed below. 565 o Known but unverified. A DN is associated with a certificate's 566 fingerprint, and additional information may be available ("contact 567 details"). When not used, such certificates may be deleted from 568 the table, after some site-specific timeout. It is RECOMMENDED 569 that this timeout be larger than 7 days. 571 o Trusted identity. The administrator can manually mark a 572 certificate as Trusted. Alternatively, the certificate may have 573 been signed by a trusted third party. 575 o Untrusted identity. The administrator can manually mark a 576 certificate as Untrusted, if he or she manually checks the 577 certificate's fingerprint and detects a mismatch against an 578 advertised value. 580 o Managed. These certificates belong to peers that are part of the 581 same managed VPN. They are not further discussed in this 582 document. 584 /-----------\ /-----------\ 585 | | successful IKE exchange | | 586 | | ==================================> | | 587 | Unknown | timeout (when allowed) |Unverified | 588 | | <================================== | | 589 | | =========== | | 590 \-----------/ || successful exchange \-----------/ 591 || || (trusted third party) || 592 || || || 593 || || manual marking || 594 || configuration || ======================== 595 || || || || 596 || || || || 597 || || || || 598 \/ || \/ \/ 599 /-----------\ || /-----------\ /-----------\ 600 | | || | | | | 601 | | ====> | | | | 602 | Managed | | Trusted | | Untrusted | 603 | | | | | | 604 | | | | | | 605 \-----------/ \-----------/ \-----------/ 607 Figure 6: Certificate States 609 If the gateway detects that a peer's certificate has been explicitly 610 revoked, it MUST delete this certificate from the table. 612 A PAD entry may exist for certificates in the Unverified, Managed or 613 Trusted states. A PAD entry MUST NOT exist for a certificate in the 614 Untrusted state, and IKE exchanges with peers presenting such 615 certificates MUST be rejected, regardless of who initiated the 616 exchange. When a certificate is deleted (whether manually or 617 automatically) or marked as Untrusted, the associated PAD entry MUST 618 be deleted. 620 When locating the peer, only the DN should be used. The peer's IP 621 address MUST NOT be used, to allow peers to change their address. 623 9.2. Certificate Rollover and Permanent Association 625 In the absence of a certificate rollover mechanism, it would be 626 impossible to distinguish between a legitimate peer presenting a new 627 certificate and a MITM attacker. Therefore, AutoVPN gateways MUST 628 support the shared secret mechanism described here. 630 As noted above, the information about a peer's certificate will 631 normally time-out and be deleted. However any of the gateways can 632 choose a convenient time to "promote" the association between the 633 gateways, by trigerring the creation of a shared secret. This secret 634 never expires, other than through manual deletion on both peers. 636 The shared secret is associated with the pair of gateway identities, 637 specifically with the IDi, IDr payloads exchanged between the 638 gateways. Once a shared secret is established, both gateways MUST 639 use it with the associated peer, in preference to certificate-based 640 or other forms of authentication. A shared secret MAY be initiated 641 for a peer in Unverified or Trusted state. On each gateway, the 642 shared secret is associated with the peer gateway's certificate, and 643 both MUST NOT be timed out regardless of the certificate's trust 644 state. 646 The initiating gateway, which may be an IKE initiator or responder, 647 MAY send the AUTOVPN_SHARED_SECRET notification at any time. The 648 shared secret is the value 650 prf+(SK_d, "shared secret for AutoVPN") 652 where SK_d is the derivation key of the current IKE SA. The literal 653 string is represented in ASCII, with no zero terminator. 655 9.3. Certificate Conflicts 657 A certificate conflict may be detected during the IKE exchange. This 658 happens when an AutoVPN peer presents a certificate whose DN matches 659 the DN of a known AutoVPN certificate, but which is different from 660 that certificate. In such cases the new peer MUST be rejected, with 661 the notification AUTHENTICATION_FAILED. 663 As a result, barring incorrect configuration, the certificate table 664 can never contain multiple certificates with the same DN. 666 9.4. Fallback to Clear 668 In some cases it may be desirable to allow fallback to clear traffic 669 in cases where an IKE/IPsec association cannot be established, even 670 when the peer is known. This is left to local policy, and SHOULD be 671 configurable on the gateway. Such configuration MAY take the trust 672 level of the peer gateway into account. 674 Moreover, some policies may prefer to send traffic unprotected, even 675 when an IKE SA can be established, and then renegotiate an IPsec SA 676 following some manual action. One possible way of doing this is 677 using the mechanism described in [RFC6023]. 679 10. IANA Considerations 681 TBD. 683 11. Security Considerations 685 TBD. 687 12. Acknowledgements 689 A proof of concept implementation of this protocol was created by 690 Michael Rogovin at Check Point, and we would like to acknowledge his 691 contribution. 693 13. References 695 13.1. Normative References 697 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 698 RFC 792, September 1981. 700 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 701 E. Lear, "Address Allocation for Private Internets", BCP 702 5, RFC 1918, February 1996. 704 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 705 Requirement Levels", BCP 14, RFC 2119, March 1997. 707 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 708 Internet Protocol", RFC 4301, December 2005. 710 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 711 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 712 April 2007. 714 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 715 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 716 5996, September 2010. 718 13.2. Informative References 720 [RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic 721 Encryption using the Internet Key Exchange (IKE)", RFC 722 4322, December 2005. 724 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 725 Security: An Unauthenticated Mode of IPsec", RFC 5386, 726 November 2008. 728 [RFC5387] Touch, J., Black, D., and Y. Wang, "Problem and 729 Applicability Statement for Better-Than-Nothing Security 730 (BTNS)", RFC 5387, November 2008. 732 [RFC6023] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A 733 Childless Initiation of the Internet Key Exchange Version 734 2 (IKEv2) Security Association (SA)", RFC 6023, October 735 2010. 737 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 738 Secure Internet Routing", RFC 6480, February 2012. 740 [oe-history] 741 Wouters, P., "History and implementation status of 742 Opportunistic Encryption for IPsec", September 2013, 743 . 747 Appendix A. Change Log 749 A.1. -00 751 Initial version. 753 Appendix B. Implementation Considerations 755 B.1. Address Authorization 757 Address authorization SHOULD be maintained separately from peer 758 identity. Timing out authorization data (as proposed in [RFC4322]) 759 is risky, since the authorization protocol allows a MITM, and also 760 exposes clear traffic. This issue is TBD, and for now, authorization 761 will only be removed when a peer is deleted. 763 We should look at alternative ways to prove address ownership. For 764 example, if the gateway G1 can prove its ownership of a certain 765 address range, it might send an RPKI [RFC6480] certificate to that 766 effect, plus proof of possession in IKE_AUTH. The peer gateway G2 767 might then decide to allow a wider traffic selector including all of 768 G1's addresses, instead of just H1. 770 Also TBD are the IPsec policy implications, within the framework of 771 [RFC4301], Sec. 4.4.3. 773 B.2. Multiple Interfaces and Alternative Gateways 775 We might want to support multiple gateway addresses in the probing 776 protocol, so we can have high quality connectivity without resorting 777 to "fallback to the clear" (i.e. have very long timeouts, measured in 778 days). On the other hand, maybe MOBIKE does the work in IKEv2. 780 Authors' Addresses 782 Yaron Sheffer 783 Porticor 785 Email: yaronf.ietf@gmail.com 787 Yoav Nir 788 Check Point Software Technologies Ltd. 789 5 Hasolelim st. 790 Tel Aviv 6789735 791 Israel 793 Email: ynir@checkpoint.com