--- 1/draft-ietf-ipsecme-ikev2-null-auth-06.txt 2015-06-03 02:14:56.569550482 -0700 +++ 2/draft-ietf-ipsecme-ikev2-null-auth-07.txt 2015-06-03 02:14:56.593551077 -0700 @@ -1,19 +1,19 @@ Network Working Group V. Smyslov Internet-Draft ELVIS-PLUS Updates: 4301 (if approved) P. Wouters Intended status: Standards Track Red Hat -Expires: October 22, 2015 April 20, 2015 +Expires: December 5, 2015 June 3, 2015 The NULL Authentication Method in IKEv2 Protocol - draft-ietf-ipsecme-ikev2-null-auth-06 + draft-ietf-ipsecme-ikev2-null-auth-07 Abstract This document specifies the NULL Authentication method and the ID_NULL Identification Payload ID Type for the IKEv2 Protocol. This allows two IKE peers to establish single-side authenticated or mutual unauthenticated IKE sessions for those use cases where a peer is unwilling or unable to authenticate or identify itself. This ensures IKEv2 can be used for Opportunistic Security (also known as Opportunistic Encryption) to defend against Pervasive Monitoring @@ -27,21 +27,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 22, 2015. + This Internet-Draft will expire on December 5, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -54,32 +54,32 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 2. Using the NULL Authentication Method . . . . . . . . . . . . . 5 2.1. Authentication Payload . . . . . . . . . . . . . . . . . . 5 2.2. Identification Payload . . . . . . . . . . . . . . . . . . 5 2.3. INITIAL_CONTACT Notification . . . . . . . . . . . . . . . 6 2.4. Interaction with Peer Authorization Database (PAD) . . . . 6 2.5. Traffic Selectors . . . . . . . . . . . . . . . . . . . . 7 - 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 3.1. Audit trail and peer identification . . . . . . . . . . . 8 - 3.2. Resource management and robustness . . . . . . . . . . . . 8 - 3.3. IKE configuration selection . . . . . . . . . . . . . . . 9 - 3.4. Networking topology changes . . . . . . . . . . . . . . . 9 - 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 - 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 - Appendix A. Update of PAD processing in RFC4301 . . . . . . . . . 13 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 + 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 3.1. Audit trail and peer identification . . . . . . . . . . . 9 + 3.2. Resource management and robustness . . . . . . . . . . . . 9 + 3.3. IKE configuration selection . . . . . . . . . . . . . . . 10 + 3.4. Networking topology changes . . . . . . . . . . . . . . . 10 + 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 + Appendix A. Update of PAD processing in RFC4301 . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction The Internet Key Exchange Protocol version 2 (IKEv2), specified in [RFC7296], provides a way for two parties to perform an authenticated key exchange. While the authentication methods used by the peers can be different, there is no method for one or both parties to remain unauthenticated and anonymous. This document extends the authentication methods to support unauthenticated and anonymous IKE sessions. @@ -121,22 +121,23 @@ 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Using the NULL Authentication Method In IKEv2, each peer independently selects the method to authenticate itself to the other side. A peer may choose to refrain from - authentication by using the NULL Authentication method. If a peer - that requires authentication receives an AUTH payload containing the + authentication by using the NULL Authentication method. If a host's + local policy requires that the identity of its peer be (non-null) + authenticated, and that host receives an AUTH payload containing the NULL Authentication method type, it MUST return an AUTHENTICATION_FAILED notification. If an initiator uses EAP, the responder MUST NOT use the NULL Authentication Method (in conformance with the section 2.16 of [RFC7296]). NULL Authentication affects how the Authentication and the Identification payloads are formed in the IKE_AUTH exchange. 2.1. Authentication Payload @@ -243,24 +244,28 @@ 2.5. Traffic Selectors Traffic Selectors and narrowing allow two IKE peers to mutually agree on a traffic range for an IPsec SA. An unauthenticated peer must not be allowed to use this mechanism to steal traffic that an IKE peer intended to be for another host. This is especially problematic when supporting anonymous IKE peers behind NAT, as such IKE peers build an IPsec SA using their pre-NAT IP address that are different from the source IP of their IKE packets. A rogue IKE peer could use malicious - Traffic Selectors to obtain access to traffic that the host never - intended to hand out. Implementations SHOULD restrict and isolate - all anonymous IKE peers from each other and itself and only allow it - access to itself and possibly its intended network ranges. + Traffic Selectors to trick a remote host into giving it IP traffic + that the remote host never intended to be sent to remote IKE peers. + For example, if the remote host uses 192.0.2.1 as DNS server, a rogue + IKE peer could set its Traffic Selector to 192.0.2.1 in an attempt to + receive the remote peer's DNS traffic. Implementations SHOULD + restrict and isolate all anonymous IKE peers from each other and + itself and only allow it access to itself and possibly its intended + network ranges. One method to achieve this is to always assign internal IP addresses to unauthenticated IKE clients, as described in Section 2.19 of [RFC7296]. Implementations may also use other techniques, such as internal NAT and connection tracking. Implementations MAY force unauthenticated IKE peers to single host- to-host IPsec SAs. When using IPv6 this is not always possible, so implementations MUST be able to assign full /64 address block to the peer as described in [RFC5739], even if it is not authenticated. @@ -289,47 +294,50 @@ assumptions that remote peers are identified. With NULL Authentication these assumptions are no longer valid. Furthermore, the host itself might have made trust assumptions or may not be aware of the network topology changes that resulted from IPsec SAs from unauthenticated IKE peers. 3.1. Audit trail and peer identification With NULL Authentication an established IKE session is no longer guaranteed to provide a verifiable (authenticated) entity known to - the system or network. Implementers that implement NULL - Authentication should ensure their implementation does not make any - assumptions that depend on IKE peers being "friendly", "trusted" or - "identifiable". + the system or network. Any logging of unproven ID payloads that were + not authenticated should be clearly marked and treated as + "untrusted", possibly accompanied by logging the remote IP address of + the IKE session. Rate limiting of logging might be required to + prevent excessive resource consumption causing system damage. 3.2. Resource management and robustness Section 2.6 of [RFC7296] provides guidance for mitigation of "Denial of Service" attacks by issuing COOKIES in response to resource consumption of half-open IKE SAs. Furthermore, [DDOS-PROTECTION] offers additional counter-measures in an attempt to distinguish attacking IKE packets from legitimate IKE peers. These defense mechanisms do not take into account IKE systems that allow unauthenticated IKE peers. An attacker using NULL Authentication is a fully legitimate IKE peer that is only distinguished from authenticated IKE peers by having used NULL Authentication. - While implementations should have been written to account for abusive - authenticated clients, any omission or error in handling abusive - clients may have gone unnoticed because abusive clients has been a - rare or non-existent problem. When adding support for - unauthenticated IKE peers, these implementation omissions and errors - will be found and abused by attackers. For example, an - unauthenticated IKE peer could send an abusive amount of Liveness - probes or Delete requests. + Implementers that implement NULL Authentication should ensure their + implementation does not make any assumptions that depend on IKE peers + being "friendly", "trusted" or "identifiable". While implementations + should have been written to account for abusive authenticated + clients, any omission or error in handling abusive clients may have + gone unnoticed because abusive clients has been a rare or non- + existent problem. When adding support for unauthenticated IKE peers, + these implementation omissions and errors will be found and abused by + attackers. For example, an unauthenticated IKE peer could send an + abusive amount of Liveness probes or Delete requests. 3.3. IKE configuration selection Combining authenticated and unauthenticated IKE peers on a single host can be dangerous, assuming the authenticated IKE peer gains more or different access from non-authenticated peers (otherwise, why not only allow unauthenticated peers). An unauthenticated IKE peer MUST NOT be able to reach resources only meant for authenticated IKE peers and MUST NOT be able to replace the Child SAs of an authenticated IKE peer.