idnits 2.17.1 draft-ietf-ipsecme-ikev2-null-auth-07.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The draft header indicates that this document updates RFC4301, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4301, updated by this document, for RFC5378 checks: 2003-10-23) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 3, 2015) is 3212 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) ** Downref: Normative reference to an Experimental RFC: RFC 5739 == Outdated reference: A later version (-10) exists of draft-ietf-ipsecme-ddos-protection-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Smyslov 3 Internet-Draft ELVIS-PLUS 4 Updates: 4301 (if approved) P. Wouters 5 Intended status: Standards Track Red Hat 6 Expires: December 5, 2015 June 3, 2015 8 The NULL Authentication Method in IKEv2 Protocol 9 draft-ietf-ipsecme-ikev2-null-auth-07 11 Abstract 13 This document specifies the NULL Authentication method and the 14 ID_NULL Identification Payload ID Type for the IKEv2 Protocol. This 15 allows two IKE peers to establish single-side authenticated or mutual 16 unauthenticated IKE sessions for those use cases where a peer is 17 unwilling or unable to authenticate or identify itself. This ensures 18 IKEv2 can be used for Opportunistic Security (also known as 19 Opportunistic Encryption) to defend against Pervasive Monitoring 20 attacks without the need to sacrifice anonymity. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 5, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 58 2. Using the NULL Authentication Method . . . . . . . . . . . . . 5 59 2.1. Authentication Payload . . . . . . . . . . . . . . . . . . 5 60 2.2. Identification Payload . . . . . . . . . . . . . . . . . . 5 61 2.3. INITIAL_CONTACT Notification . . . . . . . . . . . . . . . 6 62 2.4. Interaction with Peer Authorization Database (PAD) . . . . 6 63 2.5. Traffic Selectors . . . . . . . . . . . . . . . . . . . . 7 64 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 3.1. Audit trail and peer identification . . . . . . . . . . . 9 66 3.2. Resource management and robustness . . . . . . . . . . . . 9 67 3.3. IKE configuration selection . . . . . . . . . . . . . . . 10 68 3.4. Networking topology changes . . . . . . . . . . . . . . . 10 69 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 73 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 74 Appendix A. Update of PAD processing in RFC4301 . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 77 1. Introduction 79 The Internet Key Exchange Protocol version 2 (IKEv2), specified in 80 [RFC7296], provides a way for two parties to perform an authenticated 81 key exchange. While the authentication methods used by the peers can 82 be different, there is no method for one or both parties to remain 83 unauthenticated and anonymous. This document extends the 84 authentication methods to support unauthenticated and anonymous IKE 85 sessions. 87 In some situations mutual authentication is undesirable, superfluous 88 or impossible. The following three examples illustrate these 89 unauthenticated use cases: 91 o A user wants to establish an anonymous secure connection to a 92 server. In this situation the user should be able to authenticate 93 the server without presenting or authenticating to the server with 94 their own identity. This case uses a single-sided authentication 95 of the responder. 97 o A sensor that periodically wakes up from a suspended state wants 98 to send a measurement (e.g. temperature) to a collecting server. 99 The sensor must be authenticated by the server to ensure 100 authenticity of the measurement, but the sensor does not need to 101 authenticate the server. This case uses a single-sided 102 authentication of the initiator. 104 o Two peers without any trust relationship wish to defend against 105 widespread pervasive monitoring attacks as described in [RFC7258]. 106 Without a trust relationship, the peers cannot authenticate each 107 other. Opportunistic Security [RFC7435] states that 108 unauthenticated encrypted communication is preferred over 109 cleartext communication. The peers want to use IKE to setup an 110 unauthenticated encrypted connection, that gives them protection 111 against pervasive monitoring attacks. An attacker that is able 112 and willing to send packets can still launch a Man-in-the-Middle 113 attack to obtain a copy of the unencrypted communication. This 114 case uses a fully unauthenticated key exchange. 116 To meet these needs, this document introduces the NULL Authentication 117 method, and the ID_NULL ID type. This allows an IKE peer to 118 explicitly indicate that it is unwilling or unable to certify its 119 identity. 121 1.1. Conventions Used in This Document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 2. Using the NULL Authentication Method 129 In IKEv2, each peer independently selects the method to authenticate 130 itself to the other side. A peer may choose to refrain from 131 authentication by using the NULL Authentication method. If a host's 132 local policy requires that the identity of its peer be (non-null) 133 authenticated, and that host receives an AUTH payload containing the 134 NULL Authentication method type, it MUST return an 135 AUTHENTICATION_FAILED notification. If an initiator uses EAP, the 136 responder MUST NOT use the NULL Authentication Method (in conformance 137 with the section 2.16 of [RFC7296]). 139 NULL Authentication affects how the Authentication and the 140 Identification payloads are formed in the IKE_AUTH exchange. 142 2.1. Authentication Payload 144 NULL Authentication still requires a properly formed AUTH payload to 145 be present in the IKE_AUTH exchange messages, as the AUTH payload 146 cryptographically links the IKE_SA_INIT exchange messages with the 147 other messages sent over this IKE SA. 149 When using NULL Authentication, the content of the AUTH payload is 150 computed using the syntax of pre-shared secret authentication, 151 described in Section 2.15 of [RFC7296]. The value of SK_pi for the 152 initiator and SK_pr for the responder is used as the shared secret 153 for the content of the AUTH payload. Implementers should note this 154 means that authentication keys used by the two peers are different in 155 each direction. This is identical to how the content of the two last 156 AUTH payloads is generated for the non-key-generating EAP methods 157 (see Section 2.16 of [RFC7296] for details). 159 The IKEv2 Authentication Method value for NULL Authentication is 13. 161 2.2. Identification Payload 163 When a remote peer is not authenticated, any ID presented in the 164 Identification Data field of the ID payload cannot be validated. To 165 avoid the need of sending a bogus ID Type with placeholder data, this 166 specification defines a new ID Type, ID_NULL. The Identification 167 Data field of the ID payload for this ID Type MUST be empty. 169 If NULL Authentication is in use and anonymity is a concern then 170 ID_NULL SHOULD be used in the Identification payload. Some examples 171 of cases where a non-null identity type and value with NULL 172 Authentication can be used are logging, troubleshooting and in 173 scenarios where authentication takes place out of band after the IKE 174 SA is created (like in [AUTOVPN]). The content of the Identification 175 payload MUST NOT be used for any trust and policy checking in 176 IKE_AUTH exchange when NULL Authentication is employed (see Section 177 2.4 for details). 179 ID_NULL is primarily intended to be used with NULL Authentication but 180 could be used in other situations where the content of the 181 Identification Payload is not used. For example, ID_NULL could be 182 used when authentication is performed via raw public keys and the 183 identities are the keys themselves. These alternative uses of 184 ID_NULL should be described in their own respective documents. 186 The IKEv2 Identification Payload ID Type for ID_NULL is 13. 188 2.3. INITIAL_CONTACT Notification 190 The identity of a peer using NULL Authentication cannot be used to 191 find existing IKE SAs created by the same peer, as the peer identity 192 is not authenticated. For that reason the INITIAL_CONTACT 193 notifications MUST NOT be used to delete any other IKE SAs based on 194 the same peer identity without additional verification that the 195 existing IKE SAs with matching identity are actually stale. 197 The standard IKE Liveness Check procedure, described in Section 2.4 198 of [RFC7296], can be used to detect stale IKE SAs created by peers 199 using NULL Authentication. Inactive unauthenticated IKE SAs should 200 be checked periodically. Additionally, the event of creating a new 201 unauthenticated IKE SA can be used to trigger an out-of-order check 202 on existing unauthenticated IKE SAs, possibly limited to identical or 203 close-by IP addresses or to identical identities of the just created 204 IKE SA. 206 Implementations should weigh the resource consumption of sending 207 Liveness Checks against the memory usage of possible orphaned IKE 208 SAs. Implementations may choose to handle situations with thousands 209 of unauthenticated IKE SAs differently from situations with very few 210 such SAs. 212 2.4. Interaction with Peer Authorization Database (PAD) 214 Section 4.4.3 of [RFC4301] defines the Peer Authorization Database 215 (PAD), which provides the link between Security Policy Database (SPD) 216 and the IKEv2. The PAD contains an ordered list of records with 217 peers' identities along with corresponding authentication data and 218 Child SA authorization data. When the IKE SA is being established 219 the PAD is consulted to determine how the peer should be 220 authenticated and what Child SAs it is authorized to create. 222 When using NULL Authentication, the peer identity is not 223 authenticated and cannot be trusted. If ID_NULL is used with NULL 224 Authentication, there is no ID at all. The processing of PAD 225 described in Section 4.4.3 of [RFC4301] is updated for NULL 226 Authentication as follows. 228 NULL authentication is added as one of supported authentication 229 methods. This method does not have any authentication data. ID_NULL 230 is included into the list of allowed ID types. The matching rule for 231 ID_NULL consists only of whether this type is used, i.e. no actual ID 232 matching is done, as ID_NULL contains no identity data. 234 When using the NULL authentication method those matching rules MUST 235 include matching of a new flag in the SPD entry specifying whether 236 unauthenticated users are allowed to use that entry. I.e. each SPD 237 entry needs to be augmented to have a flag specifying whether it can 238 be used with NULL authentication or not, and only those rules that 239 explicitly have that flag turned on can be used with unauthenticated 240 connections. 242 The specific updates of text in Section 4.4.3 of [RFC4301] are listed 243 in Appendix A. 245 2.5. Traffic Selectors 247 Traffic Selectors and narrowing allow two IKE peers to mutually agree 248 on a traffic range for an IPsec SA. An unauthenticated peer must not 249 be allowed to use this mechanism to steal traffic that an IKE peer 250 intended to be for another host. This is especially problematic when 251 supporting anonymous IKE peers behind NAT, as such IKE peers build an 252 IPsec SA using their pre-NAT IP address that are different from the 253 source IP of their IKE packets. A rogue IKE peer could use malicious 254 Traffic Selectors to trick a remote host into giving it IP traffic 255 that the remote host never intended to be sent to remote IKE peers. 256 For example, if the remote host uses 192.0.2.1 as DNS server, a rogue 257 IKE peer could set its Traffic Selector to 192.0.2.1 in an attempt to 258 receive the remote peer's DNS traffic. Implementations SHOULD 259 restrict and isolate all anonymous IKE peers from each other and 260 itself and only allow it access to itself and possibly its intended 261 network ranges. 263 One method to achieve this is to always assign internal IP addresses 264 to unauthenticated IKE clients, as described in Section 2.19 of 265 [RFC7296]. Implementations may also use other techniques, such as 266 internal NAT and connection tracking. 268 Implementations MAY force unauthenticated IKE peers to single host- 269 to-host IPsec SAs. When using IPv6 this is not always possible, so 270 implementations MUST be able to assign full /64 address block to the 271 peer as described in [RFC5739], even if it is not authenticated. 273 3. Security Considerations 275 If authenticated IKE sessions are possible for a certain traffic 276 selector range between the peers, then unauthenticated IKE SHOULD NOT 277 be allowed for that traffic selector range. When mixing 278 authenticated and unauthenticated IKE with the same peer, policy 279 rules should ensure the highest level of security will be used to 280 protect the communication between the two peers. See [RFC7435] for 281 details. 283 If both peers use NULL Authentication, the entire key exchange 284 becomes unauthenticated. This makes the IKE session vulnerable to 285 active Man-in-the-Middle Attacks. 287 Using an ID Type other than ID_NULL with the NULL Authentication 288 Method may compromise the client's anonymity in case of an active 289 MITM attack. 291 IKE implementations without NULL Authentication have always performed 292 mutual authentication and were not designed for use with 293 unauthenticated IKE peers. Implementations might have made 294 assumptions that remote peers are identified. With NULL 295 Authentication these assumptions are no longer valid. Furthermore, 296 the host itself might have made trust assumptions or may not be aware 297 of the network topology changes that resulted from IPsec SAs from 298 unauthenticated IKE peers. 300 3.1. Audit trail and peer identification 302 With NULL Authentication an established IKE session is no longer 303 guaranteed to provide a verifiable (authenticated) entity known to 304 the system or network. Any logging of unproven ID payloads that were 305 not authenticated should be clearly marked and treated as 306 "untrusted", possibly accompanied by logging the remote IP address of 307 the IKE session. Rate limiting of logging might be required to 308 prevent excessive resource consumption causing system damage. 310 3.2. Resource management and robustness 312 Section 2.6 of [RFC7296] provides guidance for mitigation of "Denial 313 of Service" attacks by issuing COOKIES in response to resource 314 consumption of half-open IKE SAs. Furthermore, [DDOS-PROTECTION] 315 offers additional counter-measures in an attempt to distinguish 316 attacking IKE packets from legitimate IKE peers. 318 These defense mechanisms do not take into account IKE systems that 319 allow unauthenticated IKE peers. An attacker using NULL 320 Authentication is a fully legitimate IKE peer that is only 321 distinguished from authenticated IKE peers by having used NULL 322 Authentication. 324 Implementers that implement NULL Authentication should ensure their 325 implementation does not make any assumptions that depend on IKE peers 326 being "friendly", "trusted" or "identifiable". While implementations 327 should have been written to account for abusive authenticated 328 clients, any omission or error in handling abusive clients may have 329 gone unnoticed because abusive clients has been a rare or non- 330 existent problem. When adding support for unauthenticated IKE peers, 331 these implementation omissions and errors will be found and abused by 332 attackers. For example, an unauthenticated IKE peer could send an 333 abusive amount of Liveness probes or Delete requests. 335 3.3. IKE configuration selection 337 Combining authenticated and unauthenticated IKE peers on a single 338 host can be dangerous, assuming the authenticated IKE peer gains more 339 or different access from non-authenticated peers (otherwise, why not 340 only allow unauthenticated peers). An unauthenticated IKE peer MUST 341 NOT be able to reach resources only meant for authenticated IKE peers 342 and MUST NOT be able to replace the Child SAs of an authenticated IKE 343 peer. 345 3.4. Networking topology changes 347 When a host relies on packet filters or firewall software to protect 348 itself, establishing an IKE SA and installing an IPsec SA might 349 accidentally circumvent these packet filters and firewall 350 restrictions, as the encrypted ESP (protocol 50) or ESPinUDP (UDP 351 port 4500) packets do not match the packet filters defined. IKE 352 peers supporting unauthenticated IKE MUST pass all decrypted traffic 353 through the same packet filters and security mechanisms as incoming 354 plaintext traffic. 356 4. Acknowledgments 358 The authors would like to thank Yaron Sheffer and Tero Kivinen for 359 their reviews, valuable comments and contributed text. 361 5. IANA Considerations 363 This document defines a new entry in the "IKEv2 Authentication 364 Method" registry: 366 13 NULL Authentication 368 This document also defines a new entry in the "IKEv2 Identification 369 Payload ID Types" registry: 371 13 ID_NULL 373 6. References 375 6.1. Normative References 377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 378 Requirement Levels", BCP 14, RFC 2119, March 1997. 380 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 381 Internet Protocol", RFC 4301, December 2005. 383 [RFC5739] Eronen, P., Laganier, J., and C. Madson, "IPv6 384 Configuration in Internet Key Exchange Protocol Version 2 385 (IKEv2)", RFC 5739, February 2010. 387 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 388 Kivinen, "Internet Key Exchange Protocol Version 2 389 (IKEv2)", STD 79, RFC 7296, October 2014. 391 6.2. Informative References 393 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 394 Attack", BCP 188, RFC 7258, May 2014. 396 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 397 Most of the Time", RFC 7435, December 2014. 399 [AUTOVPN] Sheffer, Y. and Y. Nir, "The AutoVPN Architecture", Work 400 in Progress, draft-sheffer-autovpn-00, February 2014. 402 [DDOS-PROTECTION] 403 Nir, Y., "Protecting Internet Key Exchange (IKE) 404 Implementations from Distributed Denial of Service 405 Attacks", draft-ietf-ipsecme-ddos-protection-00 (work in 406 progress), October 2014. 408 Appendix A. Update of PAD processing in RFC4301 410 This appendix lists the specific updates of the text in Section 4.4.3 411 of [RFC4301] that should be followed when implementing NULL 412 Authentication. 414 A new item is added to the list of supported ID types in Section 415 4.4.3.1 417 o NULL ID (matches ID type only) 419 and the following text is added at the end of the section: 421 Added text: 422 The NULL ID type is defined as having no data. For this name type 423 the matching function is defined as comparing the ID type only. 425 A new item is added to the list of authentication data types in 426 Section 4.4.3.2 428 - NULL authentication 430 and the next paragraph is updated as follows: 432 Old: 433 For authentication based on an X.509 certificate [...] For 434 authentication based on a pre-shared secret, the PAD contains the 435 pre-shared secret to be used by IKE. 437 New: 438 For authentication based on an X.509 certificate [...] For 439 authentication based on a pre-shared secret, the PAD contains the 440 pre-shared secret to be used by IKE. For NULL authentication the 441 PAD contains no data. 443 In addition the following text is added at the end of Section 4.4.3.4 445 Added text: 446 When using the NULL authentication method implementations MUST 447 make sure that they do not mix authenticated and not-authenticated 448 SPD rules, i.e. implementations need to keep them separately, for 449 example by adding flag in SPD to tell whether NULL authentication 450 can be used or not for the entry. I.e. each SPD entry needs to be 451 augmented to have a flag specifying whether it can be used with 452 NULL authentication or not, and only those rules that explictly 453 have that flag set can be used with unauthenticated connections. 455 Authors' Addresses 457 Valery Smyslov 458 ELVIS-PLUS 459 PO Box 81 460 Moscow (Zelenograd) 124460 461 Russian Federation 463 Phone: +7 495 276 0211 464 Email: svan@elvis.ru 466 Paul Wouters 467 Red Hat 469 Email: pwouters@redhat.com