idnits 2.17.1 draft-ietf-ipsecme-ikev2-null-auth-05.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 (March 26, 2015) is 3290 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 (~~), 2 warnings (==), 1 comment (--). 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 Intended status: Standards Track P. Wouters 5 Expires: September 27, 2015 Red Hat 6 March 26, 2015 8 The NULL Authentication Method in IKEv2 Protocol 9 draft-ietf-ipsecme-ikev2-null-auth-05 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 September 27, 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 . . . . . . . . . . . . . . . . . . . 8 65 3.1. Audit trail and peer identification . . . . . . . . . . . 8 66 3.2. Resource management and robustness . . . . . . . . . . . . 8 67 3.3. IKE configuration selection . . . . . . . . . . . . . . . 9 68 3.4. Networking topology changes . . . . . . . . . . . . . . . 9 69 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 73 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 The Internet Key Exchange Protocol version 2 (IKEv2), specified in 79 [RFC7296], provides a way for two parties to perform an authenticated 80 key exchange. While the authentication methods used by the peers can 81 be different, there is no method for one or both parties to remain 82 unauthenticated and anonymous. This document extends the 83 authentication methods to support unauthenticated and anonymous IKE 84 sessions. 86 In some situations mutual authentication is undesirable, superfluous 87 or impossible. The following three examples illustrate these 88 unauthenticated use cases: 90 o A user wants to establish an anonymous secure connection to a 91 server. In this situation the user should be able to authenticate 92 the server without presenting or authenticating to the server with 93 their own identity. This case uses a single-sided authentication 94 of the responder. 96 o A sensor that periodically wakes up from a suspended state wants 97 to send a measurement (e.g. temperature) to a collecting server. 98 The sensor must be authenticated by the server to ensure 99 authenticity of the measurement, but the sensor does not need to 100 authenticate the server. This case uses a single-sided 101 authentication of the initiator. 103 o Two peers without any trust relationship wish to defend against 104 widespread pervasive monitoring attacks as described in [RFC7258]. 105 Without a trust relationship, the peers cannot authenticate each 106 other. Opportunistic Security [RFC7435] states that 107 unauthenticated encrypted communication is preferred over 108 cleartext communication. The peers want to use IKE to setup an 109 unauthenticated encrypted connection, that gives them protection 110 against pervasive monitoring attacks. An attacker that is able 111 and willing to send packets can still launch a Man-in-the-Middle 112 attack to obtain access to the decrypted communication. This case 113 uses a fully unauthenticated key exchange. 115 To meet these needs this document introduces the NULL Authentication 116 method, and the ID_NULL ID type. This allows an IKE peer to 117 explicitly indicate that it is unwilling or unable to certify its 118 identity. 120 1.1. Conventions Used in This Document 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 2. Using the NULL Authentication Method 128 In IKEv2, each peer independently selects the method to authenticate 129 itself to the other side. A peer may choose to refrain from 130 authentication by using the NULL Authentication method. If a peer 131 that requires authentication receives an AUTH payload containing the 132 NULL Authentication method type, it MUST return an 133 AUTHENTICATION_FAILED notification. If an initiator uses EAP, the 134 responder MUST NOT use the NULL Authentication Method (in conformance 135 with the section 2.16 of [RFC7296]). 137 NULL Authentication affects how the Authentication and the 138 Identification payloads are formed in the IKE_AUTH exchange. 140 2.1. Authentication Payload 142 NULL Authentication still requires a properly formed AUTH payload to 143 be present in the IKE_AUTH exchange messages, as the AUTH payload 144 cryptographically links the IKE_SA_INIT exchange messages with the 145 other messages sent over this IKE SA. 147 When using NULL Authentication, the content of the AUTH payload is 148 computed using the syntax of pre-shared secret authentication, 149 described in Section 2.15 of [RFC7296]. The values SK_pi and SK_pr 150 are used as shared secrets for the content of the AUTH payloads 151 generated by the initiator and the responder respectively. Note that 152 this is identical to how the content of the two last AUTH payloads is 153 generated for the non-key-generating EAP methods (see Section 2.16 of 154 [RFC7296] for details). 156 The IKEv2 Authentication Method value for NULL Authentication is 13. 158 2.2. Identification Payload 160 When a remote peer is not authenticated, any ID presented in the 161 Identification Data field of the ID payload cannot be validated. To 162 avoid the need of sending a bogus ID Type with placeholder data, this 163 specification defines a new ID Type, ID_NULL. The Identification 164 Data field of the ID payload for this ID Type MUST be empty. 166 If NULL Authentication is in use and anonymity is a concern then 167 ID_NULL SHOULD be used in the Identification payload. Some examples 168 of cases where a non-null identity type and value with NULL 169 Authentication can be used are logging, troubleshooting and in 170 scenarios where authentication takes place out of band after the IKE 171 SA is created (like in [AUTOVPN]). The content of the Identification 172 payload MUST NOT be used for any trust and policy checking in 173 IKE_AUTH exchange when NULL Authentication is employed (see Section 174 2.4 for details). 176 ID_NULL is primarily intended to be used with NULL Authentication but 177 could be used in other situations where the content of the 178 Identification Payload is not used. For example, ID_NULL could be 179 used when authentication is performed via raw public keys and the 180 identities are the keys themselves. These alternative uses of 181 ID_NULL should be described in their own respective documents. 183 The IKEv2 Identification Payload ID Type for ID_NULL is 13. 185 2.3. INITIAL_CONTACT Notification 187 The identity of a peer using NULL Authentication cannot be used to 188 find existing IKE SAs created by the same peer, as the peer identity 189 is not authenticated. For that reason the INITIAL_CONTACT 190 notifications MUST NOT be used to delete any other IKE SAs based on 191 the same peer identity without additional verification that the 192 existing IKE SAs with matching identity are actually stale. 194 The standard IKE Liveness Check procedure, described in Section 2.4 195 of [RFC7296], can be used to detect stale IKE SAs created by peers 196 using NULL Authentication. Inactive unauthenticated IKE SAs should 197 be checked periodically. Additionally, the event of creating a new 198 unauthenticated IKE SA can be used to trigger an out-of-order check 199 on existing unauthenticated IKE SAs, possibly limited to identical or 200 close-by IP addresses or to identical identities of the just created 201 IKE SA. 203 Implementations should weigh the resource consumption of sending 204 Liveness Checks against the memory usage of possible orphaned IKE 205 SAs. Implementations may choose to handle situations with thousands 206 of unauthenticated IKE SAs differently from situations with very few 207 such SAs. 209 2.4. Interaction with Peer Authorization Database (PAD) 211 Section 4.4.3 of [RFC4301] defines the Peer Authorization Database 212 (PAD), which provides the link between Security Policy Database (SPD) 213 and the IKEv2. The PAD contains an ordered list of records, with 214 peers' identities along with corresponding authentication data and 215 Child SA authorization data. When the IKE SA is being established 216 the PAD is consulted to determine how the peer should be 217 authenticated and what Child SAs it is authorized to create. 219 When using NULL Authentication, the peer identity is not 220 authenticated and cannot be trusted. If ID_NULL is used with NULL 221 Authentication, there is no ID at all. The processing of PAD 222 described in Section 4.4.3.4 of [RFC4301] must be updated. 224 NULL authentication needs to be added as one of supported 225 authentication methods. This method does not have any authentication 226 data. To add support for ID_NULL, it needs to be included into the 227 list of ID types, specified in Section 4.4.3.1 of [RFC4301]. The 228 matching rule for ID_NULL consists only of whether this type is used, 229 i.e. no actual ID matching is done, as ID_NULL contains no identity 230 data. 232 Section 4.4.3.3 of the [RFC4301] describes how the IKE ID is matched 233 against the SPD entries. When using the NULL authentication method 234 those matching rules MUST include matching of a new flag in the SPD 235 entry specifying whether unauthenticated users are allowed to use 236 that entry. I.e. each SPD entry needs to be augmented to have a flag 237 specifying whether it can be used with NULL authentication or not, 238 and only those rules that explictly have that flag turned on can be 239 used with unauthenticated connections. 241 2.5. Traffic Selectors 243 Traffic Selectors and narrowing allow two IKE peers to mutually agree 244 on a traffic range for an IPsec SA. An unauthenticated peer must not 245 be allowed to use this mechanism to steal traffic that an IKE peer 246 intended to be for another host. This is especially problematic when 247 supporting anonymous IKE peers behind NAT, as such IKE peers build an 248 IPsec SA using their pre-NAT IP address that are different from the 249 source IP of their IKE packets. A rogue IKE peer could use malicious 250 Traffic Selectors to obtain access to traffic that the host never 251 intended to hand out. Implementations SHOULD restrict and isolate 252 all anonymous IKE peers from each other and itself and only allow it 253 access to itself and possibly its intended network ranges. 255 One method to achieve this is to always assign internal IP addresses 256 to unauthenticated IKE clients, as described in Section 2.19 of 257 [RFC7296]. Implementations may also use other techniques, such as 258 internal NAT and connection tracking. 260 Implementations MAY force unauthenticated IKE peers to single host- 261 to-host IPsec SAs. When using IPv6 this is not always possible, so 262 in this case implementations MUST be able to assign full /64 address 263 block to the peer as described in [RFC5739], even if it is not 264 authenticated. 266 3. Security Considerations 268 If authenticated IKE sessions are possible for a certain traffic 269 selector range between the peers, then unauthenticated IKE SHOULD NOT 270 be allowed for that traffic selector range. When mixing 271 authenticated and unauthenticated IKE with the same peer, policy 272 rules should ensure the highest level of security will be used to 273 protect the communication between the two peers. See [RFC7435] for 274 details. 276 If both peers use NULL Authentication, the entire key exchange 277 becomes unauthenticated. This makes the IKE session vulnerable to 278 active Man-in-the-Middle Attacks. 280 Using an ID Type other than ID_NULL with the NULL Authentication 281 Method may compromise the client's anonymity in case of an active 282 MITM attack. 284 IKE implementations without NULL Authentication have always performed 285 mutual authentication and were not designed for use with 286 unauthenticated IKE peers. Implementations might have made 287 assumptions remote peers are identified. With NULL Authentication 288 these assumptions are no longer valid. Furthermore, the host itself 289 might have made trust assumptions or may not be aware of the network 290 topology changes that resulted from IPsec SAs from unauthenticated 291 IKE peers. 293 3.1. Audit trail and peer identification 295 With NULL Authentication an established IKE session is no longer 296 guaranteed to provide a verifiable (authenticated) entity known to 297 the system or network. Implementers that implement NULL 298 Authentication should ensure their implementation does not make any 299 assumptions that depend on IKE peers being "friendly", "trusted" or 300 "identifiable". 302 3.2. Resource management and robustness 304 Section 2.6 of [RFC7296] provides guidance for mitigation of "Denial 305 of Service" attacks by issuing COOKIES in response to resource 306 consumption of half-open IKE SAs. Furthermore, [DDOS-PROTECTION] 307 offers additional counter-measures in an attempt to distinguish 308 attacking IKE packets from legitimate IKE peers. 310 These defense mechanisms do not take into account IKE systems that 311 allow unauthenticated IKE peers. An attacker using NULL 312 Authentication is a fully legitimate IKE peer that is only 313 distinguished from authenticated IKE peers by having used NULL 314 Authentication. 316 While implementations should have been written to account for abusive 317 authenticated clients, any omission or error in handling abusive 318 clients may have gone unnoticed because abusive clients has been a 319 rare or non-existent problem. When adding support for 320 unauthenticated IKE peers, these implementation omissions and errors 321 will be found and abused by attackers. For example, an 322 unauthenticated IKE peer could send an abusive amount of Liveness 323 probes or Delete requests. 325 3.3. IKE configuration selection 327 Combining authenticated and unauthenticated IKE peers on a single 328 host can be dangerous, assuming the authenticated IKE peer gains more 329 or different access from non-authenticated peers (otherwise, why not 330 only allow unauthenticated peers). An unauthenticated IKE peer MUST 331 NOT be able to reach resources only meant for authenticated IKE peers 332 and MUST NOT be able to replace the Child SAs of an authenticated IKE 333 peer. 335 3.4. Networking topology changes 337 When a host relies on packet filters or firewall software to protect 338 itself, establishing an IKE SA and installing an IPsec SA might 339 accidentally circumvent these packet filters and firewall 340 restrictions, as the encrypted ESP (protocol 50) or ESPinUDP (UDP 341 port 4500) packets do not match the packet filters defined. IKE 342 peers supporting unauthenticated IKE MUST pass all decrypted traffic 343 through the same packet filters and security mechanisms as incoming 344 plaintext traffic. 346 4. Acknowledgments 348 The authors would like to thank Yaron Sheffer and Tero Kivinen for 349 their reviews, valuable comments and contributed text. 351 5. IANA Considerations 353 This document defines a new entry in the "IKEv2 Authentication 354 Method" registry: 356 13 NULL Authentication 358 This document also defines a new entry in the "IKEv2 Identification 359 Payload ID Types" registry: 361 13 ID_NULL 363 6. References 365 6.1. Normative References 367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 368 Requirement Levels", BCP 14, RFC 2119, March 1997. 370 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 371 Internet Protocol", RFC 4301, December 2005. 373 [RFC5739] Eronen, P., Laganier, J., and C. Madson, "IPv6 374 Configuration in Internet Key Exchange Protocol Version 2 375 (IKEv2)", RFC 5739, February 2010. 377 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 378 Kivinen, "Internet Key Exchange Protocol Version 2 379 (IKEv2)", STD 79, RFC 7296, October 2014. 381 6.2. Informative References 383 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 384 Attack", BCP 188, RFC 7258, May 2014. 386 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 387 Most of the Time", RFC 7435, December 2014. 389 [AUTOVPN] Sheffer, Y. and Y. Nir, "The AutoVPN Architecture", Work 390 in Progress, draft-sheffer-autovpn-00, February 2014. 392 [DDOS-PROTECTION] 393 Nir, Y., "Protecting Internet Key Exchange (IKE) 394 Implementations from Distributed Denial of Service 395 Attacks", draft-ietf-ipsecme-ddos-protection-00 (work in 396 progress), October 2014. 398 Authors' Addresses 400 Valery Smyslov 401 ELVIS-PLUS 402 PO Box 81 403 Moscow (Zelenograd) 124460 404 Russian Federation 406 Phone: +7 495 276 0211 407 Email: svan@elvis.ru 409 Paul Wouters 410 Red Hat 412 Email: pwouters@redhat.com