idnits 2.17.1 draft-ietf-ipsecme-ikev2-null-auth-02.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 (January 13, 2015) is 2942 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) == Outdated reference: draft-ietf-ipsecme-ddos-protection has been published as RFC 8019 Summary: 0 errors (**), 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: July 17, 2015 Red Hat 6 January 13, 2015 8 The NULL Authentication Method in IKEv2 Protocol 9 draft-ietf-ipsecme-ikev2-null-auth-02 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 un-authenticated IKE sessions for those use cases where a peer is 17 unwilling or unable to authenticate itself. This ensures IKEv2 can 18 be used for Opportunistic Security (also known as Opportunsitic 19 Encryption) to defend against Pervasive Monitoring attacks without 20 the need to sacrifice anonimity. 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 July 17, 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 . . . . . . . . . . . . . 4 59 2.1. Authentication Payload . . . . . . . . . . . . . . . . . . 4 60 2.2. Identity Payload . . . . . . . . . . . . . . . . . . . . . 4 61 2.3. INITIAL_CONTACT Notification . . . . . . . . . . . . . . . 5 62 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 3.1. Audit trail and peer identification . . . . . . . . . . . 6 64 3.2. Resource management and robustness . . . . . . . . . . . . 6 65 3.3. IKE configuration selection . . . . . . . . . . . . . . . 7 66 3.4. Networking topology changes . . . . . . . . . . . . . . . 7 67 3.5. Priviledged IKE operations . . . . . . . . . . . . . . . . 8 68 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 72 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 The Internet Key Exchange Protocol version 2 (IKEv2), specified in 78 [RFC7296], provides a way for two parties to perform an authenticated 79 key exchange. While the authentication methods used by the peers can 80 be different, there is no method for one or both parties to remain 81 unauthenticated and anonymous. This document extends the 82 authentication methods to support unauthenticated key exchanges. 84 In some situations mutual authentication is undesirable, superfluous 85 or impossible. The following three examples illustratate these un- 86 authenticated use cases: 88 o A user wants to establish an anonymous secure connection to a 89 server. In this situation the user should be able to authenticate 90 the server without presenting or authenticating to the server with 91 their own identity. This case uses a single-sided authentication 92 of the responder. 94 o A sensor that periodically wakes up from a suspended state wants 95 to send a measurement (e.g. temperature) to a collecting server. 96 The sensor must be authenticated by the server to ensure 97 authenticity of the measurment, but the sensor does not need to 98 authenticate the server. This case uses a single-sided 99 authentication of the initiator. 101 o Two peers without any trust relationship wish to defend against 102 widespread pervasive monitoring attacks as described in [RFC7258]. 103 Without a trust relationship, the peers cannot authenticate each 104 other. Opportunistic Security [RFC7435] states that un- 105 authenticated encrypted communication is prefered over cleartext 106 communication. The peers want to use IKE to setup an un- 107 authenticated encrypted connection, that gives them protection 108 against pervasive monitoring attacks. An attacker that is able 109 and willing to send packets can still launch an Man-in-the-Middle 110 attack to obtain access to the decrypted communication. This case 111 uses a fully anonymous un-authenticated key exchange. 113 To meet these needs this document introduces the NULL authentication 114 method, and the ID_NULL identity type. This allows an IKE peer to 115 explicitly indicate that it is unwilling or unable to certify its 116 identity. 118 1.1. Conventions Used in This Document 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 2. Using the NULL Authentication Method 126 In IKEv2, each peer independently selects the method to authenticate 127 itself to the other side. A peer may choose to refrain from 128 authentication by using the NULL Authentication Method. If a peer 129 that requires authentiation receives an AUTH payload containing the 130 NULL Authentication Method type, it MUST return an 131 AUTHENTICATION_FAILED notification. If an initiator uses EAP, the 132 responder MUST NOT use the NULL Authentication Method (in conformance 133 with the section 2.16 of [RFC7296]). 135 The NULL Authentication Method affects how the Authentication and the 136 Identity payloads are formed in the IKE_AUTH exchange. 138 2.1. Authentication Payload 140 The NULL Authentication Method still requires a properly formed AUTH 141 payload to be present in the IKE_AUTH exchange messages, as the AUTH 142 payload cryptographically links the IKE_SA_INIT exchange messages 143 with the other messages sent over this IKE SA. 145 When using the NULL Authentication Method, the content of the AUTH 146 payload is computed using the syntax of pre-shared secret 147 authentication, described in Section 2.15 of [RFC7296]. The values 148 SK_pi and SK_pr are used as shared secrets for the content of the 149 AUTH payloads generated by the initiator and the responder 150 respectively. Note that this is identical to how the content of the 151 two last AUTH payloads is generated for the non-key-generating EAP 152 methods (see Section 2.16 of [RFC7296] for details). 154 The KEv2 Authentication Method value for the NULL Authentication 155 Method is 13. 157 2.2. Identity Payload 159 When a remote peer is not authenticated, any ID presented in the 160 Identification Data field of the Identification Payload cannot be 161 validated and MUST be ignored. A new Identification Payload ID Type 162 is introduced to avoid the need of sending a bogus ID Type with 163 placeholder data. Furthermore, sending a traditional ID field might 164 unwittingly compromise the anonimity of the peer. 166 This specification defines a new ID Type of ID_NULL, which SHOULD 167 only be used with the NULL Authentication Method. The Identification 168 Data field of the Identification Payload MUST be empty. 170 The IKEv2 Identification Payload ID Type for ID_NULL is 13. 172 2.3. INITIAL_CONTACT Notification 174 The identity of the peer which uses the NULL Authentication Method 175 cannot be used to distinguish between IKE SAs created by different 176 peers. For that reason the INITIAL_CONTACT notifications MUST be 177 ignored for IKE SAs using the NULL Authentication Method. 179 When a new IKE SA is established using the NULL Authentication 180 Method, implementations MAY perform a Liveness Check on all other IKE 181 SAs that were established using the NULL Authentication Method. To 182 mitigate the potential impact of sending Liveness Check messages on a 183 large number of IKE SAs, implementations are advised not to blindly 184 perform Liveness Check on every such SA, but to take into 185 considerations additional information, that may indicate that the 186 particular SA is alive. This information may include the recent 187 receipt of cryptographically protected message on the IKE SA or any 188 of its Child SAs, or a successfull Liveness Check that was performed 189 recently. 191 3. Security Considerations 193 If both peers use the NULL Authentication Method, the entire key 194 exchange becomes unauthenticated. This makes the IKE session 195 vulnerable to active Man-in-the-Middle Attacks. Un-authenticated IKE 196 sessions MUST only attempted when authenticated IKE sessions are not 197 possible for the remote host and the only alternative would be to 198 send plaintext. See [RFC7435] for details. 200 Implementations SHOULD use the ID_NULL Identity Type with the NULL 201 Authenticated Method. If an un-authenticated remote IKE peer 202 presents an Identity Type different from ID_NULL, the Identification 203 Payload data MUST NOT be used for anything except logging. 205 Using an ID Type other than ID_NULL with the NULL Authentication 206 Method compromises the client's anonimity. This should be avoided 207 for regular operation but could be temporarilly enabled, for example 208 to aid with troubleshooting diagnostics. Sending an unverifiable 209 identification for any other purpose is strongly discouraged as it 210 leads to a false sense of security, 212 IKE implementations without the NULL Authentication Method have 213 always performed mutual authentication and were not designed for use 214 with un-authenticated IKE peers. Implementations might have made 215 assumptions that are no longer valid. Furthermore, the host itself 216 might have made trust assumptions or may not be aware of the network 217 topology changes that resulted from IPsec SAs from un-authenticated 218 IKE peers. 220 3.1. Audit trail and peer identification 222 An established IKE session is no longer guaranteed to provide a 223 verifiable (authenticated) entity known to the system or network. 224 Implementations that add the NULL Authentication Method should audit 225 their implementation for any assumptions that depend on IKE peers 226 being "friendly", "trusted" or "identifiable". 228 3.2. Resource management and robustness 230 Section 2.6 of [RFC7296] provides guidance for mitigation of "Denial 231 of Service" attacks by issuing COOKIES in response to resource 232 consumption of half-open IKE SAs. Furthermore, [DDOS-PROTECTION] 233 offers additional counter-meassures in an attempt to distinguish 234 attacking IKE packets from legitimate IKE peers. 236 These defense mechanisms do not take into account IKE systems that 237 allow un-authenticated IKE peers. An attacker using the NULL 238 Authentication Method is a fully legitimate IKE peer that is only 239 distinguished from authenticated IKE peers by the Authenticaion 240 Method 242 While implementations should have been written to account for abusive 243 authenticated clients, any omission or error in handling abusive 244 clients may have gone unnoticed because abusive clients has been a 245 rare or non-existent problem. When enabling un-authenticated IKE 246 peers, these implementation omissions and errors will be found and 247 abused by attackers. For example, an un-authenticated IKE peer could 248 send an abusive amount of Liveness probes or Delete requests. 250 3.3. IKE configuration selection 252 Combining authenticated and un-authenticated IKE peers on a single 253 host can be dangerous, assuming the authenticated IKE peer gains more 254 or different access from non-authenticated peers (otherwise, why not 255 only allow un-authentcated peers). An un-authenticated IKE peer MUST 256 NOT be able to reach resources only meant for authenticated IKE peers 257 and MUST NOT be able to replace the IPsec SAs of an authenticated IKE 258 peer. 260 If an IKE peer receives an IKE_AUTH exchange requesting a NULL 261 Authentication Method from an IP address that matches a configured 262 connection for an authenticated IKE session, it MUST reject the 263 IKE_AUTH exchange by sending an AUTHENTICATION_FAILED notification. 265 3.4. Networking topology changes 267 When a host relies on packet filters or firewall software to protect 268 itself, establishing an IKE SA and installing an IPsec SA might 269 accidentally circument these packet filters and firewall 270 restrictions, as the encrypted ESP (protocol 50) or ESPinUDP (UDP 271 port 4500) packets do not match the packet filters defined. IKE 272 peers supporting un-authenticated IKE MUST pass all decrypted traffic 273 through the same packet filters and security mechanisms as plaintext 274 traffic. 276 Traffic Selectors and narrowing allow two IKE peers to mutually agree 277 on a traffic range for an IPsec SA. An un-authenticated peer MUST 278 NOT be allowed to use this mechanism to steal traffic that an IKE 279 peer intended to be for another host. This is especially problematic 280 when supporting anonymous IKE peers behind NAT, as such IKE peers 281 build an IPsec SA using their pre-NAT IP address that are different 282 from the source IP of their IKE packets. A rogue IKE peer could use 283 malicious Traffic Selectors to obtain access to traffic that the host 284 never intended to hand out. Implementations SHOULD restrict and 285 isolate all anonymous IKE peers from each other and itself and only 286 allow it access to itself and possibly its intended network ranges. 288 One of the ways to achive that is to always assign internal IP 289 addresses to un-authenticated IKE clients, as described in Section 290 2.19 of [RFC7296]. Implementations may also use other techniques, 291 such as internal NAT and connection tracking. Implementations MAY 292 force un-authenticated IKE peers to single host-to-host IPsec SAs. 294 3.5. Priviledged IKE operations 296 Some IKE features are not appropriate for un-authenticated IKE peers 297 and should be restricted or forbidden. 299 4. Acknowledgments 301 The authors would like to thank Yaron Sheffer and Tero Kivinen for 302 their reviews and valuable comments. 304 5. IANA Considerations 306 This document defines a new entry in the "IKEv2 Authentication 307 Method" registry: 309 13 NULL Authentication Method 311 This document also defines a new entry in the "IKEv2 Identification 312 Payload ID Types" registry: 314 13 ID_NULL 316 6. References 318 6.1. Normative References 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, March 1997. 323 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 324 Kivinen, "Internet Key Exchange Protocol Version 2 325 (IKEv2)", STD 79, RFC 7296, October 2014. 327 6.2. Informative References 329 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 330 Attack", BCP 188, RFC 7258, May 2014. 332 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 333 Most of the Time", RFC 7435, December 2014. 335 [DDOS-PROTECTION] 336 Nir, Y., "Protecting Internet Key Exchange (IKE) 337 Implementations from Distributed Denial of Service 338 Attacks", draft-ietf-ipsecme-ddos-protection-00 (work in 339 progress), October 2014. 341 Authors' Addresses 343 Valery Smyslov 344 ELVIS-PLUS 345 PO Box 81 346 Moscow (Zelenograd) 124460 347 Russian Federation 349 Phone: +7 495 276 0211 350 Email: svan@elvis.ru 352 Paul Wouters 353 Red Hat 355 Email: pwouters@redhat.com